Port State Changes

The Port State Changes page tracks port state transitions between consecutive scans. The ledger is populated automatically after every completed scan — each scan is diffed against the previous completed scan of the same template, per scanner vantage, and only the opened/closed transitions are recorded (unchanged ports are not re-listed). This is a core GRC feature for compliance tracking, providing evidence of network changes over time for SOC2 and ISO 27001 reporting.

Fields & columns

Name	Description
`Time`	Timestamp when the state change was detected
`IP`	IP address of the host where the port state changed
`Hostname`	Reverse-DNS name(s) for this row's IP, decorated from the SAME scan execution the row belongs to — never from the baseline scan being diffed against. Not filterable or sortable. "—" can mean no reverse-DNS evidence exists for that execution's host (not requested, still pending, the read failed, or the evidence was removed by retention — change rows are kept forever, while DNS evidence is kept for 90 days after the enrichment closes), or, for a reconciler-derived row with no scan id, that there is nothing to decorate from at all — the column does not distinguish these.
`Scanner`	The scanner (vantage point) that observed the change. Each scanner is compared with its own previous run of the template, so the same port can appear once per vantage point.
`Port`	Port number that changed state
`Protocol`	Transport protocol (TCP or UDP)
`Previous State`	Port state before the change (open, closed, or filtered)
`Current State`	Port state after the change (open, closed, or filtered)
`Service`	Detected service running on the port, if identified
`Version`	Detected service version, if identified
`Scan`	Name of the scan that detected the state change
`Receipt`	For a scanner-reported change, a link (by job id) to the execution receipt of the job that produced it. Empty for a row the server-side reconciler derived, which has no single owning job.
`Evidence`	The linked receipt's result hash — a value to cross-check against the receipt once you open it, not a lookup key.

How to

Track port state changes for compliance

Navigate to Audit > Port State Changes.
Filter by subnet or port range.
Review opened and closed port events.
Export the filtered view for compliance documentation.

Gotchas

State changes are stored in TimescaleDB for efficient time-series queries and automatic compression.
Scanner groups scanning from different vantage points may report different states for the same port, since network path or firewall rules may differ per location.
A port transitioning from "filtered" to "closed" or vice versa may indicate firewall rule changes rather than service changes.
State changes are only detected between consecutive scans of the same target. A port must have been seen in a prior scan to generate a change record.
Only state CHANGES are recorded — a port that stays open across scans is not re-listed (storage compaction). Absence of rows for a scan can mean "no changes" (it had a baseline) or "baseline scan" (no prior scan); the scan results page distinguishes these.
A change row that came from a scanner-reported (compacted) run links to the execution receipt for the job that produced it (its job id → the job receipt detail). The receipt is the proof the change is grounded in a real, fully-attempted run. Rows derived by the server-side reconciler have no single owning job, so they show no receipt link.
Each scanner is compared with the last completed scan of the same template it actually took part in, and a scanner that reported deltas last time is compared with the open set its receipt vouched for — so a scanner that missed a scan, or switched between delta and full reporting, does not re-report every open port as a change. The scan summary's "since scan #N" names the template's latest completed scan; a scanner that sat that one out is compared with an earlier scan of its own.
The evidence hash on a change row is the receipt result hash — a verification REDUNDANCY you can cross-check against the linked receipt, not the lookup key. The job id is the link; the evidence hash is the anchor you compare once you arrive.
Hostname is always the name from the execution the row belongs to (its own scan id), never the baseline scan it is being compared against — a change row and its baseline can show different hostnames if the reverse-DNS answer changed between the two scans.

API calls (1)

Method	Path	Description
GET	`/api/audit/states`	List port state changes with filtering

Changes — Tracks configuration changes rather than network state changes
Views — Tracks read access to resources rather than port state transitions
Auth — Tracks authentication events rather than network state changes
Execution Proof — The per-job receipts a compacted change row links to via job id — proof the change came from a real run
Job Receipt — The single receipt a change row opens; its result hash is the row's evidence anchor