Asset Register

The asset register is a persistent inventory of every asset your network scans have found, with the modules in each. Unlike the discovery results page, which shows what a single scan found and clears when you run another, the register keeps every asset from one scan to the next and updates it as new scans run.

Open it from the Assets entry in the sidebar. The entry and its sub-items, Register, Discover devices, Reviews and Settings, are only shown to organization administrators; a member who follows a link to one of these pages is told that it is for administrators only. Device Discovery, which fills the register, opens from Assets > Discover devices.

License requirement

The asset register is a licensed feature. If it is not part of your plan, the page says so. Scans continue to work and their results appear on the Device Discovery page regardless.

Asset list

Each row in the list represents one asset — one device the scans have found. The list is sorted by asset name, then by address; assets without a name follow the named ones, sorted by address. The columns are:

Column	Description
Asset	The name your team gave the asset, or the name the scan read. An asset with neither is named by its address, which the Address column then does not repeat.
Address	The IP address the asset was found at.
Model	The order code of the asset's lead module.
Modules	The modules identified inside the asset.
Last seen	When a scan last found this asset.
Status	Only what needs a look is marked: Unidentified for an asset that is not identified, Offline for an asset the latest scan missed, Decommissioned for an asset an administrator decommissioned, and Support ended for an asset with a module whose vendor support has ended. An asset in service with none of these has no badge.
Owner	The person, team, or role your team marked as responsible.
Criticality	The criticality rating your team assigned.
Zone	The zone the asset is in.
Data source	Whether a data source reads from the asset (see Data sources).

An owner, criticality, or zone nobody recorded shows as a dash (–).

On a narrower screen, the less important columns are hidden first, starting with Zone, Criticality and Owner; the asset's name and its Status always show.

Filtering the list

Use the search field to filter by asset name, address, order code, or serial number.

The chips under the search field split the register by lifecycle: In service, Offline for the assets the latest scan missed, and Decommissioned. Each chip shows how many assets it would show under your other filters. Click one to show only those assets, click another to add them, and click All to show every asset again.

Click Filter for the rest. Within each filter you can tick more than one answer:

• Identification — only identified or only unidentified assets.
• Data source — only assets With data source or Without data source.
• Zone — only the assets in a zone, or those in No zone. It offers the zones the register's assets are in.
• Collector — only the assets a collector found, or those This appliance found with its own scans. It offers every collector the register's assets were seen from.
• No owner — the assets nobody has been assigned to yet, useful when auditing coverage.
• Support ended — the assets with a module whose vendor support has ended.

The Filter button shows how many of these are set. Click ✕ beside it to clear them and the lifecycle chips; your search stays. On a phone, Filter opens a panel that holds the lifecycle as well, and what you picked is shown under the search field.

The count above the list shows how many assets match the current filter, and how many of those a data source reads from. When no assets match, the page says so rather than showing an empty table.

Exporting to CSV

Open Export in the page header and choose Inventory (CSV) to download the full register as a spreadsheet. The file is named with the export date. It contains all assets regardless of the current filter.

Like every CSV file the register gives you, it is plain CSV: the column names are its first line and the rows follow, so a spreadsheet, a database or an import tool reads it as it is. Every row starts with snapshot_taken_at, the moment of the export in UTC, so the date stays with the rows however you sort or copy them. The file holds one row per module; an asset with no identified module is one row with the module columns empty. The register holds what network discovery has reached, so a device missing from the file is not evidence that it is not on the network.

Alongside each asset's details and its modules, the file includes:

• application_uri and application_name — the OPC UA ApplicationUri and application name the asset's server announced during discovery, if any.
• all_addresses, all_mac_addresses, all_application_uris — every address, MAC address, and ApplicationUri the asset answers to, separated by semicolons. An asset that was merged from others may answer to more than one of each.
• lifecycle_status, decommissioned_at, decommission_reason — active for an asset in service, offline for one the latest scan that covered it did not find, decommissioned for one that was decommissioned, and for a decommissioned asset when (in UTC) and why.
• component_removed_at — for a module that scans proved removed, when (in UTC); empty for a module that is present. A removed module keeps its row but is not counted in component_count.
• zone, zone_security_level, zone_is_safety — the zone the asset is in, its target security level (SL-T), and yes or no for whether it is a safety zone. All three are empty for an asset in no zone, and zone_security_level is empty for a zone with no SL-T set.
• support_end — for a module, the date its vendor support ends, as YYYY-MM-DD; empty when none is recorded.

These are the last columns; the columns before them keep their positions.

Exporting the change log

Open Export and choose Change log (CSV)… to download everything the register recorded over a period, for example to answer an auditor. Pick the first and the last day under From and To — both days are included — and click Download CSV. The period starts as the last 90 days and can span at most 366 days; for a longer one, the dialog says so beside the days and downloads nothing, so export it a year at a time. Days are UTC days, like every time in the file. The period is by when a change happened (occurred_at).

The file lists one row per change, oldest first: every entry the assets' History shows, and every decision recorded about a module's CVEs (see Vulnerabilities). A period in which nothing changed gives a file with only its column names. Each row has:

• occurred_at and recorded_at — when the change happened and when Pulse recorded it, in UTC.
• station_id, station_name, station_address — the asset, named as the list names it today.
• event_type — what happened, such as discovered, firmware_changed, curated_field_changed, merged or status_changed; cve_decision for a CVE decision.
• actor — who made the change: the person's name, scan for a change a scan found (with the scan's number in run_id), system for one Pulse made itself, such as a risk acceptance that expired. It is empty when the person's account has since been deleted.
• module_rack, module_slot, module_order_code, module_serial_number — the module the change is about, if any.
• field, old_value, new_value — what changed, from what, to what: for example the firmware version, the address, one of the fields under Your records, or, for a CVE decision, the CVE with the previous and the new decision.
• details — what else the change recorded, such as the reason an asset was decommissioned or a CVE decision was made, and until when a risk is accepted.
• period_start, period_end, period_clock, exported_at — the same on every row: the period of the file in UTC, from the start of the first day to the start of the day after the last; occurred_at, because the period is by when each change happened; and the moment you exported the file. Asset names and addresses are as they are at that moment.

When two assets were merged, the history of the absorbed asset is listed under the asset it was merged into; after the merge is undone, under the restored asset again.

Exporting the vulnerability status

Open Export and choose Vulnerability status (CSV) to download what was found and what was decided about the CVEs of the register's modules, for example as proof of how each deficiency was handled. The file is the status at the moment you download it.

Matching only reaches modules a CVE monitor watches and the advisories the vulnerability feed carries: modules nothing identified, and modules no CVE monitor watches, are not in the file, and a CVE the feed does not carry is matched against no module, so the file is not evidence that a module has no other vulnerability. It lists one row for every CVE ever matched against a module, or that a decision was recorded for, open or closed:

• station_id, station_name, station_address — the asset that holds the module today, named as the list names it.
• module_rack, module_slot, module_order_code, module_firmware_version, module_serial_number — the module, with the firmware it runs now.
• cve_id, severity, cvss_score — the CVE, with its severity and score where the finding has them.
• state — open while the CVE still matches the module, closed once a scan no longer finds it. closed_reason says why it closed: fixed when it went away with a firmware change, no_longer_matched when it stopped matching for another reason, such as a change in the vulnerability feed.
• first_matched_at and closed_at — when the CVE was first matched against the module, and when it was found gone, in UTC.
• decision, decision_reason, risk_accepted_until — the decision in force, its reason and, for a risk acceptance, until when it is accepted. affected means nobody has recorded a decision yet; open is a decision that set the CVE back to open, such as a risk acceptance that expired.
• decision_source, decided_by, decided_at — what recorded the decision (user, expiry for a risk acceptance that ran out, merge for a decision kept when two assets were merged), who made it and when. decided_by is system for an expiry or a merge, and empty when the person's account has since been deleted.
• status_as_of, catalog_advisory_count — the same on every row: the moment the status is as of, in UTC, and how many advisories the modules were matched against, the Matched against N advisories of the asset page. catalog_advisory_count is empty while the vulnerability feed has not answered yet, so the number is not known.

Without CVE monitoring on your license, nothing is matched: the file holds only its column names and lists no CVE, as the asset page shows none.

Reviewing the register

An administrator can review the register and sign it off, for example once a quarter, so there is one record of who looked at it, when, and what it held at that moment. Below the filters, the Assets page says when the register was last reviewed and by whom, or that it has not been reviewed yet. Open Assets > Reviews in the sidebar to see every review, and click Review the register to start one.

The review screen shows what changed since the last review: the period starts at the moment the last review was signed, or 90 days back for the first review. A review's period is by when Pulse recorded a change (recorded_at in the change log), not when it happened, so a change recorded after a review — a scan that finished later, say — is in the next review even when it happened before the sign-off. For each asset something changed on, it lists the entries of its History in that period and the CVE decisions recorded on its modules, each with the decision it replaced. Below that, it lists every CVE still open on a module with the decision in force on it (see Vulnerabilities); without CVE monitoring on your license it says so instead. When the period holds more than 500 changes, the screen shows the newest 500; the frozen change log holds every one.

Write a Note if you like — what you checked, or anything an auditor should know, up to 2,000 characters — and click Sign off. Pulse records who signed (the account's display name, or its email address), when, and the note, and freezes three files as they are at that moment:

• asset-register.csv — the CSV export of the register at that moment, the same file the list would have given you then. Who signed the review and when is recorded with the review, and in the audit pack's reviews.csv.
• change-log.csv — the change log of the review's period, from the previous review's moment to this one's, by when each change was recorded (its period_clock is recorded_at). The next review's period starts where this one ends, so the change logs of two reviews in a row neither overlap nor leave a gap.
• vulnerability-status.csv — the vulnerability status at that moment.

All three files describe the same moment: a change Pulse is recording while you sign is in all three or in none. If the register is recording changes when you click Sign off — a scan being folded in, say — and is still at it a few seconds later, Pulse does not wait for it: the screen says the register is recording changes right now, nothing is signed, and your note stays as you typed it, so you can click Sign off again a moment later.

The Reviews page lists the reviews newest first, one row each: when it was signed, who signed it, the start of its note and how many files it froze. Open a row to see the period it covers, the whole note and its three files. Each file shows its SHA-256, computed when the review was signed, and Download gives you the file exactly as it was stored, however the register has changed since. To check a copy, compare its SHA-256 with the one shown, for example with sha256sum change-log.csv. The copy button next to a SHA-256 puts it on the clipboard.

A review cannot be edited or deleted. If another administrator signs a review while you are reading the screen, Pulse does not sign yours: the screen shows what changed since that review instead, so you can look again before you sign.

Setting a review interval

Your security management system decides how often the register is reviewed; TISAX, for example, asks for a defined interval rather than a particular one. Administrators set it on the Review interval tab of the register settings (Assets > Settings in the sidebar): No interval (the default), Every 3 months, Every 6 months or Every 12 months. Click Save; it applies at once.

With an interval set, the line below the filters on the Assets page also says when the next review is due:

• Review due in 42 days. — the next review is due that many days from today. It is due the interval after the last review was signed: a review signed on 14 July is due on 14 October with Every 3 months. A review signed on the last day of a month falls due on the last day of a shorter month, so 31 August plus 3 months is 30 November.
• Review due today. — today is the day it is due.
• Overdue since 10/14/2026. (highlighted) — the day it was due has passed. It stays overdue until someone signs a review; the next one is then due the interval after that review.

If the register has never been reviewed, the first review is due from the moment the interval was saved, so the line says Review due today. at once and the review is overdue from the next day. Saving the interval it already has does not move that moment; choosing another interval does. With No interval the line shows no due date.

Days are counted in the organization's timezone, the same for every administrator wherever they are. An overdue review raises no incident and sends no notification: it is shown on the Assets page and nowhere else, and register incidents stay about the plant.

Downloading the audit pack

The audit pack is what you hand an auditor: one ZIP file with everything they ask for about the register, in the order they usually ask. There are two:

• The pack as signed — click Download audit pack on any review on the Reviews page. It holds the three files that review froze, exactly as they were stored, however the register has changed since.
• The current pack — open Export on the Assets page and choose Audit pack (ZIP). Pulse builds it at that moment, from the register as it is; nobody has signed it. Its change log covers the time since the last review, or the last 90 days if the register has never been reviewed — what the next review would cover.

Both packs hold the same six files:

• snapshot.csv — the CSV export of the register. In a signed pack it is the review's asset-register.csv, the same bytes under the name the pack gives it.
• change-log.csv — the change log of the pack's period.
• vulnerability-status.csv — the vulnerability status.
• zones.csv — your zones, one row each, with description, target security level (SL-T), owner, safety flag and how many assets are in it. A review does not freeze the zones, so this file shows them as they are when you download the pack.
• reviews.csv — one row per review, oldest first: who signed it and when, the note, the period it covers and the SHA-256 of each file it froze. In a signed pack it lists the reviews up to and including that one. Without any review it holds only its header.
• README.txt — in your language: whether the pack is signed or current, when it was downloaded and by whom, the period of the change log, what each file means, and what the register covers. The register holds what network discovery has reached, and vulnerability matching reaches what the CVE catalog carries, so neither file is proof that nothing else is there.

Each pack's file name carries your organization and the date, for example pulse-audit-pack-acme-plant-2026-10-17.zip, and a signed pack's the date of its review, for example pulse-audit-pack-acme-plant-reviewed-2026-10-14.zip. In a current pack, the snapshot and the vulnerability status are the same files you get from their own exports at that moment; its change log is the one the next review would freeze, by when each change was recorded. To check a signed pack's files, compare each one's SHA-256 with its row in reviews.csv or with the review on the Reviews page, for example with sha256sum snapshot.csv.

Identification

Every asset is either identified or unidentified. An unidentified asset is marked with a badge in the list and on its page; an identified one is marked only on its page.

• Identified — at least one module reported both an order code and a serial number, or the asset's OPC UA server announced an ApplicationUri of its own. Later scans recognize the asset by those values, so it stays linked to its record even if its address changes.
• Unidentified — no module reported both values and the asset has no OPC UA ApplicationUri. The asset stays listed under the address it was last seen at. This is normal for switches, panels, and other devices without a PROFINET IO role.

A note below the list reports how many assets are unidentified. This is informational — unidentified assets are real equipment on your network and are listed for that reason.

Asset detail

Click any row to open the asset's detail page. It shows:

• Asset — address, MAC address, which appliance found it, first and last seen dates, when a scan last covered it (see Offline assets), when a data source last read it and which one (see What data sources tell the register), and identification status. If the asset was merged with others, all the addresses and MAC addresses it answers to are listed here.
• OPC UA server (observed) — the ApplicationUri and application name the asset's OPC UA server announced during discovery. These values were observed, not entered by a person. The ApplicationUri identifies the asset; the application name is shown for information only. Only shown when the asset has an OPC UA server.
• Reported by device — the LLDP system name and system description the device broadcast over the network. These are shown for information only and are not used to identify the asset.
• Modules — a table of every module found in the asset, with its rack position, type, order code, firmware version, serial number, when it was last seen, for a CPU, its current operating mode (RUN or STOP) and when it was last read, and when its vendor support ends. A module that scans proved removed stays in the table, below the others, marked Removed with the date, and is not counted among the asset's modules. With CVE monitoring, a CVE monitoring column shows whether a CVE monitor watches each module (see Monitoring a module for CVEs). When the table is too narrow for every column, Last seen is hidden first, then the serial number, the type and the support end; the position, order code, firmware and CVE monitoring always show.
• Vulnerabilities — with CVE monitoring, the CVEs matched against the asset's modules and what was decided about each (see Vulnerabilities).
• Data sources — the data sources that read from this asset (see Data sources).
• Your records — the curation fields your team fills in (see below).
• History — a log of what the register recorded about the asset: when it was discovered, and what identified it then — its OPC UA server's ApplicationUri, or a module's order code and serial number, with the module the scan found it as; when its firmware, its address or the operating mode of one of its CPUs changed; when a module was added or removed; when someone edited its details or a module's support end; when a different device was found at its address; when two assets were merged into this one, or a merge was undone; and when its status changed — a scan did not find the asset or found it again, every data source that reads it lost its connection or one of them answered again, or an administrator decommissioned or recommissioned it. Entries are only ever added; none can be changed or removed. Each entry is one line saying what changed; click it to see the details. The five newest entries are shown first; click Show more below them to see the rest of the newest 20, and again to load the next 20.

Your records

The Your records card holds what your team knows about the asset that a scan cannot find out. Scans never overwrite these fields.

Click Edit to open the form. The fields are:

Field	Description
Name	What your plant calls this asset, for example "Line 3 PLC". Shown instead of the scan name.
Owner	Who answers for it: a person, a team, or a role.
Criticality	Low, Medium, High, or Critical. Choose Not rated if this has not been assessed yet.
Location	Where the asset physically sits: hall, cabinet, rack.
Safety system	Whether the asset is part of a safety system. Choose Not assessed if nobody has decided.
Notes	Free-form notes about the asset.
Zone	The zone the asset is in. Choose No zone to take it out of its zone.

When the asset's PROFINET function tag or location tag carries a value your team typed during commissioning, the form offers to use it as the name or location. The field is only saved when you accept and click Save.

Each save that changes something adds one entry to the asset's History: it names who saved and lists every field the save changed, with its value before and after.

TIP

Criticality and Safety system have a "not yet assessed" state that is distinct from a deliberate "not critical" or "not a safety system". Use it until your team has reviewed the asset — an unreviewed entry looks different from a reviewed one.

Support end

Vendors stop supporting their modules after a while: no more firmware updates and no more security fixes. A module past that date is a risk to plan around. A scan cannot read the date from the device, so your team records it for each module, from the vendor's product lifecycle information.

To record it, open the asset and, in the Modules table, click the pencil icon in the module's Support ends column. Choose the date and click Save. To remove a date, open it again and click Clear date. The table shows who recorded the date, and Not recorded for a module without one. When the table is too narrow for the column, as on a phone, it is hidden; the asset is still marked.

From that date on, the module is marked Support ended, and so is the asset: at the top of its page and in the Status column of the asset list. The date is counted in your organization's timezone, so the mark appears at midnight local time, the same for everyone. A module that scans proved removed does not mark its asset. To find every such asset, choose Support ended under Filter in the list.

Scans never change the date. A module that is replaced by one with a different serial number, in the same rack and slot, is a new module: it has no date until your team records one. Each change of the date adds an entry to the asset's History, naming the module, with the date before and after.

When two assets are merged, each module keeps its date. When both assets held the same module, the merged module keeps the date that was recorded last. Undoing the merge gives each module its own date back, unless someone changed it after the merge.

If another administrator changed the date while you had the page open, your save is not applied: the page shows their date instead, and you can edit it again.

The CSV export carries the date in its support_end column.

Zones

Zones group assets that share the same security requirements, as IEC 62443 does: by risk and criticality, not by network. An asset is in one zone or in none. The ⓘ beside Zones in the register settings explains zones, conduits and the security levels, and links the ISA Global Cybersecurity Alliance's free quick start guide to IEC 62443.

Administrators keep the zones on the Zones tab of the register settings (Assets > Settings in the sidebar). Click Add zone and fill in:

Field	Description
Name	For example "Cell 2" or "Packaging line". Zone names are unique in your organization, ignoring case.
Target security level (SL-T)	The security level the zone is meant to reach, from 0 to 4, as IEC 62443 defines it, or Not set.
Owner	Who answers for the zone: a person, a team, or a role.
Safety zone	Whether the zone is designated a safety zone, one that serves functional safety, protecting people and the plant.
Description	Free-form notes about the zone.

Each zone in the list shows its SL-T, whether it is a safety zone, its owner, and how many assets are in it. Click a zone's pencil icon to edit it.

To put an asset in a zone, open the asset, click Edit under Your records, choose the zone under Zone, and click Save. The card then shows the zone with its SL-T and, for a safety zone, a Safety zone badge. Like every other field there, the change is recorded in the asset's History, with the zone's name before and after. Renaming a zone later does not change the entries already recorded.

Setting the zone of many assets

To put many assets in a zone at once, use the asset list:

1. Filter the list down to the assets you want. A collector usually sits in one network segment, so the Collector filter is often a good start, but a collector's assets are not a zone: you decide which zone they belong in.
2. Click Select next to Filter. Click the assets, or tick Select all above the table to select every asset shown. Hold Shift while you click to select every asset between the last one you clicked and this one.
3. In the bar at the bottom of the page, click Set zone…, choose a zone or No zone, and confirm.

Changing a filter clears the selection, so only assets you can see are changed. Up to 1000 assets can be set at once. Press Esc to clear the selection, and Esc again, or Select once more, to leave selection mode. Selection mode is not offered on phones.

Each asset is saved as if its own record had been saved, and its History records the change with the zone's name before and after. An asset that is already in the chosen zone is left as it is, with no history entry. An asset that another administrator changed after you loaded the list is not changed either: the result names it, so you can open it, check what was changed, and set its zone again. Every other asset is saved.

When the result appears, it says how many assets were put in the zone, how many were already in it, and which were changed by someone else in the meantime. Pulse never assigns a zone on its own.

The asset list shows each asset's zone in its Zone column, and can be filtered by zone. The CSV export carries the zone, its SL-T, and whether it is a safety zone.

A zone that assets are in cannot be deleted: the delete dialog says how many assets are in it. Take them out of the zone first, then delete it. Deleting a zone cannot be undone.

When two assets are merged, the merged asset keeps the zone of the asset you merged the other one into, as it keeps that asset's other values; the other asset's zone is not taken over, but its name at the time of the merge is recorded in the merge entry of the History, and in the change log. Undoing the merge does not put the restored asset back in the zone it was in before.

Merge proposals

A CPU and its communication processor each answer at an address of their own, so the register lists them as two assets. The register looks for such pairs: an asset with only a CPU and an asset with only a communication processor, seen from the same appliance or collector, whose IPv4 addresses are in the same /24 subnet and are each other's nearest, with no other asset just as near. When it finds one, a banner appears at the top of the asset list.

Each proposal shows the two assets, the subnet they share, how far apart their addresses are, and, for assets found through a collector, which collector saw them. The proposal is based on address proximity alone; it never uses asset names.

• Click Review merge… to open the merge dialog for the pair (see below).
• Click Not one cabinet to dismiss the suggestion. The two assets will not be proposed again.

Nothing changes until you act — a proposal is a suggestion only.

Merging assets

Merge two assets when they are actually one cabinet in the register — for example, a CPU and its communication processor that each answer at a separate address.

You can start a merge in two ways:

1. From a merge proposal — click Review merge… on the proposal banner.
2. From the asset list — click Select next to Filter, then click the two assets. In the bar at the bottom of the page, click Merge…. It is available when exactly two assets are selected.

In the merge dialog, choose which asset to keep. The asset you keep takes over the addresses, MAC addresses, ApplicationUris, and modules the scans found on the other, together with the CVE monitors and CVE decisions on those modules, the data sources that read from the other asset, and the firmware change, module removed and new device incidents raised about it. The asset you keep also retains its own name, owner, criticality, location, safety system flag, and notes — values from the absorbed asset are not carried over, but are recorded in the history of the asset you keep.

Assets seen from different collectors cannot be merged. The same address behind two collectors can be two different devices.

Unmerging assets

If a merge was a mistake, you can undo it. Open the asset that absorbed the other and click Unmerge asset… at the top of the page. The button undoes the newest merge into the asset; the merge itself is listed in the History card.

The register restores the absorbed asset under the id it had before. Its addresses, MAC addresses, ApplicationUris, and modules are returned to it, as are the values your team entered for it, its history, the data sources that read from it, and the incidents raised about it. The asset you kept retains the values your team entered for it — including any changes made after the merge.

Only the newest merge into an asset can be undone. To undo an older one, undo the newer merges first. One case cannot be undone at all: when the asset you kept was later merged into a third asset and that merge was undone, the older merges into it can no longer be undone. The unmerge dialog says so.

Offline assets

An asset is offline when the latest completed scan that covered its address did not find it, or when every data source that reads it lost its connection (see What data sources tell the register). Pulse does not mark an asset offline because time has passed: plants go quiet for weeks during a shutdown, and Pulse only scans when someone starts a scan. A later scan that finds the asset again brings it back into service on its own.

A scan covers an asset when all of the following hold:

• it ran on the same appliance or collector that found the asset;
• it examined the asset's address with a method that ran to the end and could have found it — S7 for an asset with S7 modules, OPC UA for an asset with an OPC UA server;
• the collector that ran it records what it covered. Collectors running an older version do not, and their scans never mark an asset offline.

An S7 scan looks for controllers on port 102, the standard S7 port, unless an entry of its Network range names another port for a host, such as 192.168.10.5:1102. It covers an asset with S7 modules only on the port the asset answers on: the port of the S7 data source that reads it or, when no S7 data source reads it, the port a scan last found it on. So a controller that a data source reads on port 1102 is not marked offline by a scan that looked only on port 102 — its data source keeps telling the register whether it is there. The same holds for a controller without a data source that a scan found on port 1102. To have scans judge it as well, include its port in the scan's network range.

A scan whose method failed, a scan of another network, or a scan from another collector leaves the asset as it was. An asset known only from PROFINET discovery is never marked offline, because PROFINET discovery does not examine addresses. An asset that was merged from several is offline only when the scan found it at none of its addresses. A scan's miss counts only when the scan started after a data source last read the asset: a data source that read it since says it is there.

An offline asset:

• is marked Offline in the list and at the top of its page;
• shows which scan missed it, since when it has been offline, and when a scan last covered it;
• gets an entry in its History, recorded by the scan. So does coming back.

Offline is only as current as the last scan that covered the asset: the Last covered by a scan date on the asset's page says how old that is. To check again, run a scan of the asset's network.

An offline asset is still in service, but it is flagged separately: the list counts it under Offline, not under In service, and the CSV export shows offline in lifecycle_status. An asset that is not decommissioned and is not offline — neither the latest scan that covered it nor its data sources say it is — shows an In service badge on its page; the list leaves it unmarked. A decommissioned asset is marked Decommissioned whatever its scans say.

Decommissioning an asset

The register never removes an asset on its own: an asset that scans have not found for a while stays listed, marked offline, because plants go quiet for weeks at a time. When equipment is actually taken out of service, decommission it.

Open the asset and click Decommission… at the top of the page. Enter the reason (required, up to 1,000 characters) and click Decommission. The asset:

• stays in the register and in the CSV export, marked Decommissioned;
• shows at the top of its page who decommissioned it, when, and why;
• gets an entry in its History, with the reason.

Scans keep updating a decommissioned asset. If a scan finds it again, its Last seen date moves, but it stays decommissioned until an administrator recommissions it.

To put the asset back into service, open it and click Recommission. The asset is no longer marked as decommissioned; its History keeps both the decommissioning, with its reason, and the recommissioning. If a scan or a data source still says the asset is offline at that moment, the confirmation says so — the asset is recommissioned, but shows as offline until a scan finds it or a data source reads it again.

If you merge a decommissioned asset into one that is in service, the asset you keep stays in service. Undoing that merge restores the absorbed asset as decommissioned, with who decommissioned it, when, and why.

Data sources

A data source reads from an asset when it connects to the address the asset was found at, through the same appliance or collector. When a data source's address is a host name, the address that name resolved to counts: the appliance or collector that reads the data source reports it after the first successful read. The asset's page lists those data sources with links to them. When none does, the page says so: the register never creates a data source. You add one from Device Discovery or the data sources page, and it is listed here once it reads from the asset.

The data source's own page shows the asset it reads from as Reads from and the asset's name, linked to the asset. Like the register, this link is shown only to organization administrators.

What data sources tell the register

Scans run only when someone starts one, but a data source reads its asset all the time. What it reads keeps the register current between scans:

• Last seen live. The asset's page shows when a data source last read the asset successfully, and which one, linked to it. It is updated at most once a minute. An asset no data source has read yet says Not read by a data source yet; if the data source has since been deleted, the page says so. Last seen stays the date a scan last found the asset.
• CPU operating mode. An S7 data source reads the operating mode of the CPU at its rack and slot along with its values. When it reads RUN where the register held STOP, or the other way round, the register records the new mode and adds an entry to the asset's History, marked Read live from and the data source. A read that cannot tell the mode changes nothing, and a reading older than what a scan recorded never replaces it.
• Firmware. An S7 data source also reads the order code, serial number and firmware of the CPU at its rack and slot — on the connection it already holds, never a second one — when it first connects to the device and then every 10 minutes. When the firmware differs from what the register holds, the register records the new firmware, adds a firmware change to the asset's History, marked Read live from and the data source, and raises the same incident a scan's firmware change would. This happens only when the data source reached the address the asset is linked by and the module's order code and serial number are the ones the register holds. If a different module answers, the data source changes nothing: only the next scan decides whether the device was replaced. A scan that read the old firmware before the data source read the new one never puts the old firmware back. Appliances and collectors running an older Pulse release do not read the firmware.
• Offline and back. When every enabled data source that reads the asset has lost its connection — the device did not answer, the connection timed out, or Pulse is holding off a device that keeps failing — the asset is marked offline without waiting for a scan. The top of its page says when its data sources lost their connection. A device that answered and refused — a read it rejected, a login or certificate it did not accept — is there, so it keeps the asset in service. As soon as one of its data sources reads it again, the asset is back. Both changes are entries in its History, naming the data source.

Newer evidence wins between scans and data sources: a data source answering brings back an asset a scan missed only when it answered after that scan, and a scan's miss counts only when the scan started after a data source last read the asset.

When two assets are merged, the asset you keep shows the later of their Last seen live dates. An asset restored by undoing a merge shows none until one of its data sources reads it again.

Monitoring a module for CVEs

With CVE monitoring, the CVE monitoring column of the Modules table shows, for each module:

• The CVE monitors that watch it, each linked, with its number of open findings (Open or In progress), or No open findings.
• Monitor for CVEs, when no monitor watches the module yet.
• No order code recorded, so it cannot be matched against advisories, when the module has no order code. Advisories are matched on the order code, so such a module cannot be monitored.

To start monitoring a module:

1. Click Monitor for CVEs in the module's row.
2. Check the dialog. It shows the module, its order code and its firmware. These come from the asset register and follow the module at every scan.
3. Adjust the Name if needed. It defaults to the asset's name followed by the order code.
4. Confirm the Vendor. The register records no manufacturer, so the dialog fills in Siemens. Advisories are matched on the vendor too.
5. Choose an escalation policy, and add tags if you use them.
6. Click Start monitoring.

The result is an ordinary CVE monitor that takes its device from this module. Nothing starts a monitor except this click: a scan never creates one.

Vulnerabilities

With CVE monitoring, the Vulnerabilities section of the asset's page answers what was decided about each CVE on this asset. A decision is recorded on the module, not on a monitor, so it stays here even after the monitor is deleted. See Decisions recorded on the module.

When a CVE monitor watches at least one module, the section opens with what the modules were checked against: Matched against N advisories, last checked and when the newest scan of the asset's monitors ran. The number of advisories is refreshed by the hourly CVE scan, so it can be up to an hour old. If the Pulse gateway, which provides the vulnerability feed, has never answered, the number is left out and the line only says when the modules were last checked.

Each module a CVE monitor watches, or that has decisions recorded, is listed with when it was last checked. A module the newest network scan did not find is marked Not seen in the latest scan. Its decisions still show, because a decision about a module that was swapped out is still part of the record.

Under each module, every matched CVE shows its severity and title, and links to the finding. It also shows:

• The current decision — its status and reason, who made it and when. A risk acceptance also shows the date it is accepted until. Without one, the CVE shows No decision recorded.
• Fixed by a firmware change — the CVE no longer matches because the module's firmware changed. No longer matched means it stopped matching for another reason.
• History — click to list every decision made about this CVE on this module, oldest first. Each entry says where it came from:
  • by and a person's name, for a decision someone recorded. It is the user's current name, so a renamed user shows their new name. If that user is later removed from Pulse, the entry says by a removed user.
  • Risk acceptance expired, when a risk acceptance reached its date and the CVE went back to Open.
  • Kept on merge, when two assets that held the same module were merged and each had a decision for this CVE. The decision of the asset you kept stays current, and the other asset's decisions stay in the history.

To record a decision, click Record decision next to the CVE. It opens the same triage dialog as the Vulnerabilities pages, with the same statuses and rules, including Mitigated for a vulnerability a compensating control blocks. The decision shows on the CVE pages straight away. The button is shown while a CVE monitor watches the module.

The section closes with Modules not checked for CVEs: every module of the asset that no CVE monitor watches, with the reason — No CVE monitor watches this module, or no order code to match against. Matching only covers modules that are watched, so this list shows plainly what is not covered.

License requirement

The CVE parts of the asset page — the CVE monitoring column and the Vulnerabilities section — need CVE monitoring on your license as well as the asset register. Without it, they are not shown.

Routing register incidents

The asset register raises an incident when a scan or an S7 data source reads different firmware on a module of a registered asset, when scans prove that a module was removed from it, or when a scan finds a new device where an earlier scan found nothing (see Firmware changes on assets, Modules removed from assets and New assets on scanned networks). The register settings decide who hears about it. Administrators open them with Assets > Settings in the sidebar.

• Notify admins only (the default) — every administrator and owner of the organization gets an in-app notification. Nobody is paged.
• An escalation policy — every register incident also escalates through that policy, as an incident of a monitor on it would: its steps, recipients, severities and operating hours apply, and nobody acknowledging it runs the policy's repeats and hand-off. The in-app notification to administrators is still sent.

Choose a policy under Escalation policy on the Incidents tab and click Save. The setting applies to incidents raised after you save it; an incident that is already open keeps the routing it was raised with.

Nothing is paged until an administrator picks a policy here. The organization's default escalation policy is not used for register incidents.

While the register routes its incidents through a policy, that policy cannot be deleted. Pick another policy or Notify admins only first.

Example: page only outside working hours

During the working day someone is usually on site who knows about a firmware update; at night or at the weekend an unannounced change is worth waking someone for. To page only outside working hours, create an escalation policy with two steps:

1. An Operating hours step: mode Weekdays, hours 08:00 to 17:00, with Invert operating hours switched on. Inverted, the step lets the escalation continue only outside those hours: on weekday evenings and nights, and all weekend.
2. A notify step (Add Step) with the on-call schedule as its recipient.

Then choose this policy in the register settings. A firmware change found at 10:00 on a Tuesday waits at the first step; the incident's activity feed shows Escalation paused — outside operating hours and when it will resume, at 17:00. Acknowledge and resolve it before then and nobody is paged. A change found at 22:00 is not held: it goes on to the notify step at once, and the on-call schedule is paged after that step's initial delay.

Operating hours are evaluated in the organization's timezone.

Maintenance windows

A planned firmware update or module swap need not page anyone. Maintenance windows are the times such changes are made: a firmware change, a removed module or a new asset made wholly inside one is recorded in the asset's History as usual, marked In maintenance window with the window it fell in, and raises no incident.

Administrators edit the windows on the Maintenance windows tab of the register settings (Assets > Settings in the sidebar). Click Add window, choose Weekdays, Every day or Custom days, set the hours, and click Save. To remove a window, click its bin icon and save. A register holds at most 20 windows; the form says so when you have reached the limit. With none, the default, every change raises an incident. Saving applies to changes recorded from then on: entries already in an asset's history keep the mark they were given. Switching to another settings tab keeps unsaved changes; if you navigate away from the settings page before saving, it asks whether to discard them.

Windows are read in the organization's timezone, which the tab names, so a window from 06:00 to 14:00 stays 06:00 to 14:00 local time across a daylight-saving change. A window ends on the day it starts, at 24:00 (midnight) at the latest, so a window from 22:00 to 24:00 holds the last two hours of the day. Giving a window the same start and end covers the whole day, 24 hours from its start, and the tab says so beside it.

When a change counts as made in a window

A scan does not see a change when it is made, only afterwards. So Pulse does not ask when the scan ran, but when the change could have been made: anywhere between the scan that last saw the old state and the scan that saw the new one.

• A firmware change: from the scan or S7 data source that last read the old firmware to the one that read the new one.
• A removed module: from the last scan that found the module to the scan that recorded the removal.
• A new asset: from the start of the earlier scan that found its address empty to the scan that found the device.

The change counts as made in a window only when that whole stretch lies inside maintenance: inside one window, or inside windows that follow on from one another without a gap. A whole-day window on Monday and one on Tuesday, for example, together hold a change made across Monday midnight.

Example. A window covers weekdays from 06:00 to 14:00. A scan at 08:00 on Monday reads firmware 2.8.1 on a CPU, and a scan at 11:00 reads 2.9.4. The change was made between 08:00 and 11:00, inside Monday's window: it is recorded, marked, and raises no incident. Had the last scan before it run at 20:00 on Sunday, and the next one at 09:00 on Monday, the change could have been made on Sunday night, outside every window: it raises an incident, although the scan that found it ran inside the window.

The closer together your scans run, the more precisely Pulse knows when a change was made. A scan run just after a window opens lets a change made later in the window count as made in it.

Only a change that would otherwise raise an incident is marked. A change that raises none anyway — without the asset register in your license, from a scan added more than 24 hours after it finished, or on a decommissioned asset — is recorded without a mark.

Related pages

• Device Discovery — run a scan to populate the register
• Vulnerabilities (CVEs) — CVE monitors, findings, and triage
• Licenses — enable the asset register on your plan