An external attack surface management (EASM) platform holds the most complete list of your internet-facing weaknesses that exists anywhere, plus read access into your cloud accounts and DNS, so whoever controls it skips the attacker's reconnaissance phase entirely. EASM tools take seed data such as domains, IP ranges and company names, discover related assets, probe them, and rank exposures such as open admin interfaces, expiring certificates, dangling DNS records and leaked credentials. This guide is for security operations, vulnerability management and platform owners who run such a tool. It covers what the platform holds, admin roles, seed and scope governance, cloud and DNS connectors, scanning engines, leaked credential data, the platform's own logs and lifecycle. How to run an attack surface programme is in the Attack Surface Management Guide; this page is about protecting the tool itself. It is vendor-neutral: confirm exact setting names in your vendor's documentation.
Key takeaways
- The exposure list is a target list. Ranked, validated external findings are exactly what an attacker would build with reconnaissance (T1595, T1596); protect them as sensitive data.
- Connectors are privileged non-human identities. Cloud, DNS and CMDB integrations need read-only, per-account credentials with owners and expiry, never broad admin roles.
- Seeds decide who gets scanned. An unverified seed points active probing at someone else's systems; verify ownership before a seed goes live.
- Leaked credential findings are secrets. Mask them, route them to a reset process and limit who can view them in clear.
- Allowlisted scanner addresses are a bypass. The NCSC asks you to document network changes made for hosted scanning; keep that exception narrow and monitored.
What the platform holds and can do
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Console and tenant settings | Users, roles, seeds, business unit structure, integrations | Reads every exposure, adds seeds, adds admins | SSO with phishing-resistant MFA, few admins, scoped roles |
| Seed and scope data | Domains, IP ranges, ASNs, subsidiaries, brand names | Redirects scanning to third parties or hides your assets from scope | Verified seeds, change approval, alerts |
| Asset inventory | Every discovered host, service, certificate and cloud resource, including forgotten ones | A complete map of your perimeter (T1590) | Access by business unit, export controls |
| Exposure findings and evidence | Open admin panels, vulnerable versions, screenshots, banners, validation results | A prioritised exploitation list (T1213) | Restricted access, encryption, retention |
| Leaked credential and dark web findings | Usernames, sometimes passwords or tokens, from breach and paste data | Working credentials (T1589.001) | Masking, restricted role, automatic routing to reset |
| Cloud, DNS and CMDB connectors | Read roles in cloud accounts, DNS provider API keys, CMDB tokens | Reads cloud configuration, or edits DNS if keys can write (T1078.004) | Read-only, per-account credentials, federation where supported |
| Scanning and validation engines | Send probes and safe checks to your assets | Disruptive checks against production or third parties (T1595) | Policy by asset class, scan windows, registered source addresses |
| Outbound integrations | Ticketing, chat, SIEM, vulnerability management | Leaks findings to the wrong place | Per-integration credentials, destination allowlist |
Admin roles and console access
- Role design: separate platform administrator (settings, roles, integrations), scope administrator (adds and verifies seeds), analyst (triages findings), asset owner (sees and remediates exposures for their business unit), credential exposure handler (sees unmasked leaked credential findings) and read-only reporter.
- Scope by business unit: subsidiaries and regional teams should see their own assets. In our view, giving every remediation owner the whole group's exposure list is an avoidable risk, especially after a merger when the acquired company's teams are new.
- Authentication: SSO with phishing-resistant MFA, roles from identity provider groups, and one tested break-glass account. The CISA and FBI Secure by Demand guide suggests asking whether SSO is offered at no extra cost and whether MFA or passkeys are on by default. See the Break-Glass Account Guide.
- Admin devices: follow the NCSC secure system administration principles: trusted management devices, protected administration interfaces, privileged access management and logging of all administration. See the Privileged Access Workstations Guide.
- Consultants and MSSPs: named, time-bound accounts limited to the business units in their contract. See the Third-Party Access Guide.
Seed and scope governance
Discovery starts from seeds and expands by association: shared certificates, registrant details, name servers, address blocks. Associations are often wrong, and an incorrect attribution means probing systems you do not own. The NCSC guidance on vulnerability scanning tools and services asks organisations to identify all assets, ideally in an asset register, group them into logical scan scopes and record anything excluded from scanning.
- Verify seeds: a seed becomes active only when ownership is confirmed against registrar records, the internet registry allocation, your cloud accounts or the asset register, and a named owner accepts it.
- Separate discovery from probing: passive discovery (certificate transparency, DNS, internet scan datasets) can run across candidates; active probing and validation run only against confirmed assets.
- Approve scope changes: adding or removing a seed, a business unit or an exclusion needs the scope administrator role and raises an alert. Removing a seed is as dangerous as adding one, because it hides assets from monitoring.
- Record exclusions: follow the NCSC advice to record excluded assets, keep fragile-host exclusions as short as possible and note them in the risk register.
- Review attribution: review low-confidence attributions monthly (our recommendation) and after mergers, divestments and domain transfers.
Cloud, DNS and CMDB connectors
Many EASM platforms import assets directly from cloud accounts and DNS providers to improve accuracy. Each connector is a non-human identity in a system you care about. See the Cross-Account and Cross-Tenant Access Guide and the External attack surface management (EASM) integration security guide.
| Connector | Needs | Avoid | Pattern |
|---|---|---|---|
| Cloud account import | List public addresses, load balancers, DNS zones, storage endpoints | Broad read-all roles that include data plane reads or secrets | Custom inventory-only role per account, cross-account role with an external ID or workload federation, no static keys |
| DNS provider API | List zones and records | Keys that can edit records | Read-only key per provider account; DNS changes go through your own change process |
| Registrar data | List registered domains and expiry | Account owner credentials for the registrar | Read-only API or export; registrar admin stays with the DNS owner. See the Authoritative DNS and Registrar Account Security Guide. |
| CMDB and asset register | Read ownership, write discovered assets for review | Admin tokens that can delete records | Scoped integration account, writes into a staging table |
| Ticketing and chat | Create tickets, post alerts | Personal tokens of an employee | Service account with project-level rights only |
- Owner and expiry: every connector credential has an owner, a review date and a rotation date (at least every 90 days for static secrets, our recommendation).
- Monitor in the source system: alert in the cloud account or DNS provider when the connector identity acts outside its usual calls or source addresses, not only in the EASM tool.
- Remove dead connectors: accounts closed or divested still have trust relationships pointing at the platform until someone deletes them.
Scanning engines, validation and allowlists
- Safe policy by asset class: the NCSC asks buyers to get assurance that scanning will not disrupt services, and to be able to exclude dangerous checks if not. Disable intrusive validation for production assets unless an owner has approved it.
- Scan windows and source addresses: register the platform's scanning addresses with the SOC so authorised probing can be told apart from attacks.
- Keep allowlists narrow: if you allowlist scanner addresses through a firewall, WAF or IPS, the NCSC says such network changes should be documented and included in your risk model. Allow only the specific addresses and destinations, and review them when the vendor changes ranges.
- Self-hosted or internal engines: harden them, restrict their egress to their targets and the platform, and remove standing interactive access.
Leaked credential and exposure data
Many EASM tools surface credentials found in breach dumps, paste sites and public code. A leaked password or API key in clear text inside the platform is a second copy of the secret.
- Mask by default: show leaked credentials masked to all but a credential exposure handler role, and log every unmask.
- Route, do not store: send each confirmed live credential to the owning team's reset or revocation process and record closure. See the Leaked Credential Response Playbook.
- Machine credentials: exposed API keys and tokens are often the highest-impact findings, since they rarely have MFA. Treat them as incidents, not tickets. The JSONFormatter and CodeBeautify leak showed how many live secrets sit in public pastes.
- Retention and residency: set retention for screenshots, banners and evidence, confirm where a hosted platform stores data, and ask how vendor staff access is approved and logged. The NCSC notes that with a hosted solution, confidentiality depends on trusting the vendor's controls.
The platform's own logs
| Event to capture | Why it matters | Alert? |
|---|---|---|
| Role, SSO or user change | Persistence and widened access (T1098) | Always |
| Seed added or removed; business unit changed | Scanning third parties or hiding assets | Always |
| Connector created or credential changed | New path into cloud or DNS | Always |
| Leaked credential unmasked | Secret exposure | Always |
| Bulk export or API read of findings or inventory | Data theft (T1213) | Above baseline |
| Finding closed as accepted risk or false positive | Hides a real exposure | Critical severity or bulk |
| Scan policy changed to intrusive on production | Outage risk | Always |
- Export it: stream the audit log to a SIEM the platform's admins cannot change (NIST SP 800-53 AU-9(2) and AC-6(9)).
- Retention: Secure by Demand asks SaaS providers to keep security logs for at least six months at no extra charge, covering configuration changes, identity events and data access; export if your plan keeps less.
Lifecycle
| Stage | Security actions |
|---|---|
| Buy | Ask the Secure by Demand questions; confirm business unit scoping, seed verification, read-only connectors with federation, credential masking, audit export, data residency and vendor staff access. See the Attack Surface Management Buyer's Guide and the External attack surface management (EASM) RFP template. |
| Deploy | SSO first; roles and business units; verified seeds; read-only connectors; safe scan policies; scanner addresses registered with the SOC; audit export on day one. See the External attack surface management (EASM) rollout playbook. |
| Run | Monthly attribution review; quarterly review of roles, connectors, allowlists and accepted risks; rotate static connector secrets. |
| Respond | If the platform or a connector is suspected compromised, follow If your external attack surface management (EASM) is compromised: revoke connector credentials in the source systems, review seeds, exports and closed findings, and fix the most exposed assets first. |
| Retire | Export the inventory history you must keep, delete connector roles and keys in every cloud and DNS account, remove scanner allowlists, and obtain written confirmation of data deletion (MP-6). |
Roll back a hardening change, such as narrowing a connector role, by restoring only the specific permission the import reports as missing, never a broad managed read-all role.
Choosing controls by size
- Small organisations: often run EASM as a managed service. Focus on SSO and MFA, read-only connectors, masked credentials and knowing who at the provider can see your findings.
- Groups with many subsidiaries: business unit scoping, seed verification and attribution review matter most, because scope errors multiply with every acquisition.
- Regulated or sensitive estates: the NCSC advises against hosted solutions for air-gapped networks or those holding highly sensitive information; keep those out of the platform's scope and cover them another way.
Detection and measurement
- Percentage of active seeds with verified ownership and a named owner (target: 100 per cent).
- Number of users who can view the whole group's exposures or unmasked credentials (target: five or fewer, our suggestion).
- Connectors with write permissions, admin roles or static secrets older than 90 days (target: zero).
- Leaked machine credentials confirmed revoked, and median time to revoke.
- Critical findings closed as accepted risk without an expiry (target: zero).
- Days of platform audit log available in the SIEM.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | Threat addressed |
|---|---|---|---|
| Console roles and business unit scoping | AC-2, AC-6, AC-6(5) | PR.AA-05 | T1078 Valid Accounts |
| Seeds, scope and inventory | CM-8, PM-5 | ID.AM-01, ID.AM-02 | T1595 Active Scanning (misuse of the tool) |
| Exposure findings and monitoring | RA-5, CA-7 | ID.RA-01 | T1213 Data from Information Repositories |
| Cloud and DNS connectors | IA-5, AC-6 | PR.AA-01 | T1078.004 Cloud Accounts |
| Scanner allowlists | SC-7 | ID.AM-03 | T1590 Gather Victim Network Information |
| Audit log protection | AU-9(2), AC-6(9) | PR.PS-04 | T1098 Account Manipulation |
| Hosted service and vendor access | SA-9, SR-3 | GV.SC-07 | T1199 Trusted Relationship |
Common failure patterns
- Read-all cloud roles: the connector was given the broadest managed read role, which can also read data and configuration secrets.
- DNS keys that can write: an integration key created for convenience could change records for every zone.
- Unverified seeds: a mistyped or wrongly attributed range sends active probing to another organisation.
- Clear-text leaked passwords: credential findings visible to every analyst, and exported into tickets.
- Broad scanner allowlists: the vendor's whole address range bypasses the WAF for every application.
- Quiet scope removal: seeds deleted without review, so newly exposed assets never appear.
Practitioner checklist
- Treat exposure findings, inventory and leaked credential data as sensitive, with access, retention and deletion rules.
- Enforce SSO with phishing-resistant MFA, group-based roles and a tested break-glass account.
- Separate platform, scope, analyst, asset owner and credential handler roles, and scope by business unit.
- Verify every seed before active probing, and alert on seed additions and removals.
- Use read-only, per-account connectors with federation where supported, owners and rotation dates.
- Mask leaked credentials and route each live one to revocation.
- Keep scanner allowlists narrow, documented and reviewed.
- Export the platform audit log to a SIEM its admins cannot change.
- Review roles, connectors, allowlists, attribution and accepted risks on a fixed schedule.
Standards and references
- NCSC: Vulnerability scanning tools and services
- NCSC: Secure system administration
- CISA and FBI: Secure by Demand Guide
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Search Open Technical Databases
- MITRE ATT&CK: Active Scanning
Related NHI Mgmt Group resources: Attack Surface Management Guide · External attack surface management (EASM) health check · Subdomain Takeover and Dangling DNS Guide · Securing the vulnerability scanner itself · Dark Web Monitoring Guide