Sensors
A sensor is the Lumen Edge collector you run inside your own network. It is the platform's only foothold on your side of the boundary, and everything that touches your systems happens there: every integration run, every API call to a source system, every packet a scan sends.
The console holds the inventory and decides what work needs doing. The sensor does the work.
You can deploy as many sensors as your network needs — most organizations run several, one per site or segment.
There is no need to install anything on your endpoints. A sensor is a collector, not an agent: one of them covers thousands of assets, because the information comes from the integrations it runs — your EDR, your directory, your cloud subscriptions — and from what it can probe or observe on the network. You deploy sensors for reach, so that every source system and every segment has one that can get to it, never for coverage of individual machines.
What a sensor is responsible for
| Responsibility | What it means in practice |
|---|---|
| Running integrations | Every integration in the catalogue is assigned to a sensor, and the sensor is what calls the source system's API |
| Scanning the network | The active scanner probes from the sensor; the passive scanner listens on the sensor's feed |
| Uploading results | Raw findings are archived and posted back to the console, which does the interpretation |
| Reporting its own health | Version, hostname, addresses and a status message, refreshed on every check-in |
It is worth stressing, because it is the single most common misunderstanding: integrations are not console-side jobs that reach into your network. They are tasks the sensor runs. If a sensor cannot reach a source system — no route, no proxy, an expired credential — that integration cannot run, and the console has no other path to the data.
How the sensor talks to the console
The connection is outbound only, and initiated by the sensor. Nothing connects to a sensor, and no inbound firewall rule is ever needed for one.
| Property | Value |
|---|---|
| Direction | Sensor → console |
| Transport | HTTPS to the console's API |
| Authentication | A long-lived sensor API token, sent as an x-api-key header |
| Cadence | A polling loop; the default interval is 30 seconds |
| Proxy | Supported, configured in the sensor's own config file |
Each cycle, the sensor asks for its queued tasks, starts any it has been given, and reports progress. That same request is what refreshes the sensor's last seen time in the console — so a sensor with nothing to do still checks in, and a stale last-seen means the sensor is not running or cannot reach the console.
How a sensor picks up work
The sensor periodically pulls updates from the console, checking whether there is anything new for it — a configuration change, or a task to execute.
When you create a new integration instance you always specify the sensor that will run it. So by the time a scanning task starts, which sensor is going to run it is already well defined: the task goes to that sensor, it does the work, and it uploads the result back to the console.
Tasks run in parallel threads on the sensor, so one slow integration does not block the others, and a sensor that restarts requeues whatever it had in flight rather than losing the schedule.
The stages a task passes through, and which of them run on the sensor rather than in the console, are set out in Scanning.
Enrolling a sensor
Enrolment is a two-token exchange. A short-lived deployment token identifies the tenant a new sensor may join; the sensor trades it once for its own long-lived API token and never uses the deployment token again.
In the console
Settings → Sensors → Add sensor walks through it:
- Select platform — Docker, Windows, macOS or Linux.
- Select deployment token — reveal or copy the tenant's token. Requires sensor management permission on the tenant; see Roles and permissions.
- Download the sensor — from the console, or with the
curl/wget/ PowerShell command shown. - Select connection type — direct, or through a proxy for an air-gapped installation.
- Enrol and start — put the token in the sensor's configuration and start it.
A tenant has at most one active deployment token. Minting a new one invalidates every earlier token immediately — a half-finished rollout that was going to reuse the old value will start failing. Sensors that have already enrolled are unaffected, because they no longer depend on it.
The token expires an hour after it is issued. If it lapses before you have enrolled the host, generate a new one and start again — expiry affects only enrolment, never a sensor that has already enrolled.
Registration creates the sensor as Sensor-<hostname> and it appears in
maintenance status until it has settled. Rename it from the sensor detail view to
something that says where it sits — dc-core-span, branch-rome — because
that is the question you will be asking when you assign integrations to it.
System requirements
The sensor is a lightweight collector. Typically it needs no more than 2 vCPU and 2 GB of RAM, on a Linux host with a container runtime — see Deployment options. Beyond that it wants modest local disk, because results are staged and archived on the host before they are uploaded, and an NTP-synchronised clock, because tokens carry expiry times and every finding it produces is timestamped.
What it costs to run still depends on the work you give it:
| Sensor role | Dominated by |
|---|---|
| API integrations only | Almost nothing between polls; brief bursts while a sync runs and its result is compressed |
| Active scanning | CPU and network during a run, and disk proportional to the number of addresses scanned and pages probed |
| Passive capture | Sustained CPU and memory proportional to the throughput of the mirrored feed, whatever the size of the estate |
Publish disk sizing per scanned address count, and the maximum feed throughput a single passive sensor sustains.
Network requirements
Everything is outbound and sensor-initiated. No inbound rule to a sensor is ever required, and nothing in the platform connects to one.
| From | To | Protocol | Port |
|---|---|---|---|
| Sensor | The Lumen Edge console | HTTPS over TCP | Whatever the console URL names — 443 normally |
| Sensor | DNS resolver | DNS | 53 |
| Sensor | Your outbound proxy, where one is used | As the proxy requires | Carries the console traffic and integration calls |
| Sensor | Source systems it reads | Per integration — LDAPS, Kibana, a Nessus manager and so on | See each integration's page |
The console traffic is the only rule every sensor needs. The rest follow from the integrations you assign to it, which is another argument for deciding placement first — see Where to place sensors, and how many.
Where outbound traffic is intercepted, the sensor sees the proxy's certificate rather than the console's. Install the proxy's CA on the sensor host; the alternative — turning certificate verification off in the sensor's config — makes every call the sensor makes trust anything, including the ones carrying your integration credentials.
Deployment options
The sensor is meant to be installable the way your platform team already installs things. Not all of those paths exist yet, and each has a page for installing and a page for upgrading:
| Method | Status | Install | Upgrade |
|---|---|---|---|
| Linux, Docker | Available today | Install | Upgrade |
| Linux, system service | Planned | Install | Upgrade |
| Windows service | Planned | Install | Upgrade |
Whichever path you take, enrolment is the same exchange described above: the deployment token goes in, an API token comes back, and the sensor starts polling. Only the packaging differs.
Its platform selector already offers Windows, macOS and Linux alongside Docker. Until those packages ship, the choices do not change what you get — deploy with Docker.
Where to place sensors, and how many
A sensor's usefulness is decided almost entirely by where it sits — which is why the count follows from your network, not from the size of your estate. A single sensor with internet egress can inventory the whole company if every source is a SaaS API; a segmented network with several sites needs one per island. Two questions settle it:
What does it need to reach? An integration runs on one sensor, so that sensor needs a route to that source system — a domain controller, an internal Nessus manager, a Kibana instance. SaaS sources only need general internet egress, so one sensor with outbound access covers all of them.
What does it need to see? An active scan can only probe what its sensor can route to, and a passive scan can only observe what its feed carries. Both are per-segment concerns.
| Situation | Sensors |
|---|---|
| One site, flat routing, SaaS integrations only | One |
| Several sites with firewalls between them | One per site |
| A segment you must scan but cannot route into | One inside it |
| A mirrored feed you want to listen to | One attached to that feed |
| A DMZ or OT zone with strict egress | One inside it, with a proxy if required |
Opening inter-segment ACLs so one sensor can scan everything makes that sensor a high-value target and a lasting hole in your segmentation. A second sensor with outbound HTTPS only is cheaper to justify and easier to defend.
Managing a sensor
The sensor list shows every sensor in the tenant with its status, mode, version and last check-in. Opening one shows what it has reported about itself and what you can change:
| Shown | Meaning |
|---|---|
| Name, description | Yours to set — the only editable fields |
| Status | Health as the sensor last reported it |
| Mode | Whether the sensor is enabled for work |
| Version | The sensor build, useful when a fleet is mid-upgrade |
| Type | The sensor's role |
| Hostname | As the host reports it |
| Private IP | Every address the host holds |
| Public IP | The address the console saw it from |
| Sensor created, last seen | Enrolment time and the last check-in |
Actions on the detail view cover testing the sensor, updating the agent, disabling it and deleting it.
Status and mode are different things
| Values | Set by | |
|---|---|---|
| Status | Healthy, Maintenance, Fault, Offline | The sensor, reported on check-in |
| Mode | Enabled, Disabled | You, in the console |
Status is a report. Mode is an instruction: a disabled sensor stops being given work while remaining enrolled, which is what you want during host maintenance, a network change, or while investigating whether a scan is causing trouble.
A sensor that dies cannot report that it has died. What you have is last seen — refreshed every polling cycle — so a last-seen more than a few minutes old is the real signal, whatever the status column says. Sensor offline and sensor fault are also notification types, so the platform can tell you rather than waiting for you to look.
Disabling versus deleting
Disabling stops the work and keeps everything else: the enrolment, the sensor's history, and every asset it has discovered. Deleting removes the sensor from the tenant, which invalidates its token — the host keeps running until it fails to authenticate. In both cases the assets it discovered stay in the inventory; they simply stop being refreshed.
When a sensor stops reporting
The failure is quiet, which is what makes it dangerous:
- The sensor stops checking in.
- Its integrations stop running, so their assets stop being refreshed.
- Last-seen timestamps age.
- Coverage degrades, and nothing in the inventory looks broken.
An asset last seen weeks ago has not necessarily been decommissioned — its sensor
may be the thing that is down. Check sensor health before acting on a last-seen
date, and think twice before setting Asset missing to Delete asset on any
integration. See Integrations.
A checklist when a sensor goes quiet:
| Check | Where |
|---|---|
| Is it still checking in? | Last seen, in the sensor list |
| What did it last say? | The sensor's status message |
| Is it disabled? | Mode, on the sensor detail view |
| Is the host running? | The container, on the host |
| Can it reach the console? | Outbound HTTPS, and the proxy setting if there is one |
| Is its token still valid? | Deleting a sensor in the console invalidates it |
| Are its tasks stuck? | Scan history, filtered to that sensor's integrations |
See also
- Install a sensor on Linux (Docker) and Upgrade a sensor on Linux (Docker) — the supported deployment
- Linux (service) and Windows — the planned packages
- Active scanner — probing from the sensor
- Passive scanner — listening from the sensor
- Integrations — the catalogue and the shared configuration model
- Scanning — templates, schedules and run history
- Core concepts — where the sensor sits in the model