Most organisations run an attack surface scan, yet few can say how much of their internet-facing estate they actually know about, who owns each asset, or how fast an exposed admin interface gets closed. Owning a scanner is a step, not a level of maturity. This model uses NHI Mgmt Group's five levels, Ad hoc to Optimised, to describe how attack surface management (ASM) progresses across four dimensions: discovery, ownership, exposure validation and remediation, with identity exposure as a cross-cutting thread. It is for security leaders who need to report a credible maturity score and for practitioners who need to pick the next improvement. For the discipline itself (techniques, tools and data sources), see the Attack Surface Management Guide; this page does not repeat it.
Key takeaways
- The five levels are Ad hoc, Developing, Defined, Managed and Optimised, scored separately for discovery, ownership, exposure validation and remediation.
- Ownership is the usual ceiling. Organisations that discover well but cannot route a finding to an accountable owner stay at Level 2 however good their tooling.
- Level 3 is the first sensible target: weekly automated discovery, an owner on every internet-facing asset, and written exposure timelines that match CISA's published benchmarks.
- Level 4 adds validation: findings are confirmed as reachable and exploitable before they are prioritised, so teams fix what attackers can actually use.
- Measure outcomes, not scan counts: unknown-asset rate, assets without an owner, and median time to close a critical exposure tell you whether the programme works.
The five levels
| Level | Name | What it looks like |
|---|---|---|
| 1 | Ad hoc | No authoritative list of domains, IP ranges or cloud accounts. Exposures are found by outsiders, bug reports or incidents. Scans run occasionally, often before an audit. |
| 2 | Developing | An external scanning service or tool runs on known ranges. Results land in a shared mailbox or spreadsheet. Many findings have no owner and age without action. Cloud and SaaS assets are partly covered. |
| 3 | Defined | An ASM standard sets discovery frequency, asset ownership and exposure-closure timelines. Discovery is automated at least weekly and seeds from registrars, certificate transparency, DNS and cloud provider APIs. Every internet-facing asset has a named owner, and findings flow into ticketing. |
| 4 | Managed | Findings are validated for reachability and exploitability and prioritised with threat context such as the CISA Known Exploited Vulnerabilities catalogue. Discovery is continuous and reconciled with the CMDB. Metrics are reported monthly, and exceptions expire. |
| 5 | Optimised | New assets are registered and protected at creation through provisioning pipelines and guardrails, so shadow exposure is rare. Common exposure classes are closed automatically. Results feed red team, threat modelling and procurement, and the model is re-scored twice a year. |
Capability dimensions
Score each dimension separately and take the lowest of the four as the programme's honest level. A control that exists on paper but covers part of the estate scores Level 2.
| Dimension | Level 1 Ad hoc | Level 3 Defined | Level 5 Optimised |
|---|---|---|---|
| Discovery | Known IP list only; no seed from registrars, DNS or cloud accounts | Automated discovery at least every 7 days from registrar, DNS, certificate transparency, cloud APIs and acquisitions; unknown assets triaged within a set time | Continuous discovery; new assets appear in inventory from provisioning pipelines before they are reachable |
| Ownership and context | Owner unknown for most assets | Every internet-facing asset tagged with owner, business service, environment and data classification | Ownership enforced at creation; orphaned assets automatically quarantined or removed |
| Exposure validation | Raw scanner output; many false positives | Findings deduplicated and checked against KEV and severity; manual confirmation for criticals | Automated, safe validation of reachability and exploitability; results linked to attack paths |
| Remediation | Fixes when someone notices; no timelines | Written timelines by exposure class, tracked in ticketing, with time-limited exceptions | Common classes (exposed management interfaces, dangling DNS) closed automatically; median closure in days |
| Identity exposure | Leaked keys and exposed login portals not in scope | Secret scanning of public repositories and exposed files; inventory of external login portals with MFA status | Exposed credentials revoked automatically; every external access path tied to a phishing-resistant or workload identity control |
Benchmarks you can calibrate against
CISA's binding operational directives for US federal agencies are the clearest public benchmarks for ASM cadence, even for organisations they do not bind.
| Source | Requirement | Level it implies |
|---|---|---|
| CISA BOD 23-01 (October 2022) | Automated asset discovery every 7 days covering the full IPv4 space; vulnerability enumeration every 14 days, including roaming devices; on-demand discovery within 72 hours of a CISA request | Level 3 discovery |
| CISA BOD 23-02 (June 2023) | Internet-exposed management interfaces of routers, switches, firewalls, VPN concentrators, proxies, load balancers and out-of-band server management (such as iLO or iDRAC) removed from the internet or placed behind separate zero trust access control within 14 days of discovery | Level 3 remediation for the highest-risk exposure class |
| CISA BOD 22-01 (November 2021) | Known exploited vulnerabilities remediated within two weeks for CVEs from 2021 onwards, and within six months for older CVE IDs, unless CISA sets other dates | Level 3 to 4 prioritisation |
| CIS Controls v8.1 | Safeguard 1.1 enterprise asset inventory, 1.3 active discovery tool, 1.5 passive discovery, 7.6 automated external vulnerability scans | Levels 2 to 3 baseline |
The model maps to these framework references, confirmed against the official catalogues:
| Framework | Reference | What it asks for |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01, ID.AM-02, ID.RA-01, ID.RA-06 | Hardware and software inventories; vulnerabilities identified, validated and recorded; risk responses prioritised and tracked |
| NIST SP 800-53 Rev. 5 | CM-8, CM-8(3), RA-5, CM-7, SC-7 | Component inventory with automated detection of unauthorised components; vulnerability scanning; least functionality; boundary protection |
| MITRE ATT&CK v20 | T1595, T1596, T1190, T1133 | Active Scanning and Search Open Technical Databases (what attackers do to map you); Exploit Public-Facing Application and External Remote Services (what Levels 1 and 2 leave open) |
Self-assessment questions
Answer for internet-facing assets first, then extend to cloud control planes and SaaS. Score each answer 1 to 5.
- Discovery seeds: do you discover from registrar accounts, DNS zones, certificate transparency logs, every cloud account and recent acquisitions, or only from a list of known IP ranges?
- Cadence: how often does automated discovery run, and how long would it take to find a server a developer exposed yesterday? Is that within the 7 days BOD 23-01 sets?
- Unknown-asset rate: of the assets discovery found last quarter, what share was not already in your inventory?
- Ownership: could you name the accountable owner of every internet-facing asset within one working day? How many have none?
- Management interfaces: are any firewall, VPN, hypervisor or out-of-band management interfaces reachable from the internet today, and how long has each been exposed?
- External access: do all remote access portals, including legacy ones, enforce MFA? In the Change Healthcare breach, attackers used stolen credentials on a Citrix remote-access portal that did not require MFA.
- Validation: are criticals confirmed as reachable and exploitable before prioritisation, and are KEV-listed findings fast-tracked?
- Remediation timelines: are closure timelines written down by exposure class, and what share of last quarter's criticals met them?
- Exceptions: do accepted exposures have an owner, a compensating control and an expiry date?
- Identity exposure: do you scan public code and exposed files for your API keys and tokens, and revoke found credentials before cleaning up the source?
Moving up a level
- Level 1 to 2: get visibility. Compile seeds (registrars, DNS zones, cloud accounts, certificate transparency), run an external scan, and send the first findings to named teams. Do not wait for perfect inventory. See the Certificate Transparency Monitoring Guide for Web Teams.
- Level 2 to 3: assign ownership and timelines. Make owner, service and environment mandatory tags on every internet-facing asset. Write an ASM standard with discovery cadence and closure timelines (start with 14 days for exposed management interfaces and the BOD 22-01 timelines for KEV entries). Route findings into ticketing, not email. Pilot with two business units, then extend.
- Level 3 to 4: validate and prioritise. Add safe validation of reachability and exploitability, enrich with the KEV catalogue, and reconcile discovered assets with the CMDB monthly. Make exceptions expire. Report the metrics below monthly. See the Exposure Management and CTEM Guide.
- Level 4 to 5: prevent at source. Register assets in provisioning pipelines, block public exposure of management ports with cloud guardrails, auto-remediate dangling DNS and auto-revoke exposed credentials. Feed results into threat modelling and acquisition due diligence.
Testing and rollback: run automated remediation in report-only mode for a month before enforcing, and keep a documented rollback (restore the DNS record, re-open a security group rule with a time limit) for each automated action. Small versus large organisations: a small organisation can reach Level 3 with a managed external scanning service, a spreadsheet of owners reviewed monthly and free government services where eligible, such as CISA Cyber Hygiene, which offers weekly vulnerability scanning reports for internet-facing assets to eligible US organisations. Large and acquisitive organisations need continuous discovery and CMDB reconciliation to hold Level 3.
Metrics that show maturity
| Metric | Level 2 | Level 3 | Level 4 and above |
|---|---|---|---|
| Unknown-asset rate (new discoveries not in inventory) | Not measured | Measured quarterly, falling | Low and stable; spikes investigated |
| Internet-facing assets without an owner | Majority | Under 10 percent | Near zero; orphans quarantined |
| Median time to close exposed management interfaces | Weeks to months | Within 14 days | Hours to days, often automatic |
| KEV findings closed within policy timeline | Not tracked | Tracked | Consistently met |
| Exposed credentials revoked within 24 hours | Not tracked | Manual, tracked | Automated |
| Expired exceptions still open | No expiry | Reviewed | Zero |
Common failure patterns
- Scanning only known ranges: the riskiest assets are the ones nobody listed, such as acquired domains, test tenants and developer cloud accounts.
- Findings without owners: a report full of unassigned findings is Level 2 regardless of tool quality.
- Treating legacy remote access as low risk: old VPN and Citrix portals often miss MFA and are a common route in.
- Ignoring identity exposure: leaked keys and tokens are attack surface. See the Misconfiguration exposures lessons guide.
- Permanent exceptions: exposures accepted once and never revisited.
- Dangling DNS: deleted cloud resources with live CNAME records. See the Subdomain Takeover and Dangling DNS Guide.
Practitioner checklist
- Score all four dimensions plus identity exposure and take the lowest as the programme level.
- Seed discovery from registrars, DNS, certificate transparency, every cloud account and acquisitions.
- Run automated discovery at least every 7 days and triage unknown assets.
- Make owner, service and environment mandatory on every internet-facing asset.
- Close exposed management interfaces within 14 days and fast-track KEV-listed findings.
- Enforce MFA on every external access path, including legacy remote access.
- Validate criticals for reachability before prioritising and give every exception an expiry.
- Report the six metrics monthly and re-score the model every six months.
Standards and references
- CISA: BOD 23-01, Improving Asset Visibility and Vulnerability Detection on Federal Networks
- CISA: BOD 23-02, Mitigating the Risk from Internet-Exposed Management Interfaces
- CISA: BOD 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities
- CISA: Cyber Hygiene Services
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: Reconnaissance (TA0043)
Related NHI Mgmt Group resources: Attack Surface Management Guide · Attack Surface Management Buyer's Guide · Vulnerability Management Maturity Model · CISA KEV Catalogue Guide · Exposure Management and CTEM Guide