A hosted scanner is a deployment model where the scanning service runs in the provider's cloud environment and connects to the customer's source system over configured access. It reduces setup effort, but the organisation must still control permissions, scope, and authentication to avoid unnecessary exposure.
Expanded Definition
A hosted scanner is a security scanning service operated in the provider’s cloud while connecting back to a customer system through approved network paths and authenticated access. It is not the scan target itself; it is the execution model for the scanner, which changes where control, trust, and data handling sit.
This model is common for vulnerability scanning, compliance checks, configuration assessment, and discovery tasks where the provider maintains the engine, updates, and orchestration. The customer still owns scope, credentials, segmentation, and the decision about which assets can be reached. That boundary is often misunderstood: “hosted” does not mean “hands-off,” because the scanner usually needs enough access to enumerate systems and read signals that can be sensitive.
In practice, the key distinction is between OWASP Non-Human Identity Top 10 style access concerns and a simple SaaS usage model. A hosted scanner may still depend on machine credentials, API tokens, certificates, or agentless network trust to do its job.
Examples and Use Cases
Hosted scanners appear in environments where central management is easier than deploying and maintaining local scanning infrastructure. They are attractive when teams need rapid onboarding, distributed coverage, or frequent scans without managing scanner uptime.
- Cloud account assessment that reads configurations and exposed services through a read-only role.
- External attack surface discovery that maps internet-facing assets from the provider’s environment.
- Application security or container registry scanning initiated from a vendor cloud control plane.
- Agentless infrastructure checks that query hosts through approved management ports or APIs.
- Multi-team compliance scanning where one managed service standardises schedules and reporting.
The main tradeoff is convenience versus trust concentration. A hosted scanner reduces local operational burden, but it also centralises scanning authority and makes the permission model more important than the deployment label. If the access scope is broad, the scanner can observe far more than the team intended.
Security Implications
A hosted scanner can create exposure if the access path is over-permissioned, too persistent, or poorly segmented. Because the service often needs credentials or network reach into customer environments, a compromise of the scanner account, token, or control plane can widen the blast radius beyond a single asset set.
Misconfiguration is the most common failure mode. A read-only role that is not actually read-only, a token that is reused across many systems, or firewall rules that open more than the scanner needs can turn a maintenance tool into a high-trust connector. That is especially risky when scan data includes asset inventories, software versions, exposed services, or authentication metadata.
NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which is relevant here because hosted scanners often rely on exactly those machine identities. If teams cannot see where scanner credentials are used, revocation and rotation become difficult and residual access can linger after a vendor change or incident.
Domain and Governance Relevance
In NHI security, hosted scanners are important because they sit at the boundary between a managed service and machine-to-machine access. The scanner may be legitimate infrastructure, but it still needs identity, privilege, lifecycle ownership, and revocation discipline like any other non-human actor.
That changes governance in two ways. First, the organisation must treat scanner credentials as managed machine identities, not as incidental setup details. Second, teams must define who owns scope changes, what data the scanner can collect, and how access is removed when the service is retired or replaced. Without that discipline, hosted scanning can become a hidden dependency that outlives its intended purpose.
For NHI programs, the practical question is not whether the scanner is hosted. It is whether the access it uses is visible, least-privileged, and recoverable under normal offboarding controls.
Risk and Threat Considerations
Hosted scanners concentrate trust: a single cloud-operated service may hold credentials, broad network reach, or API permissions across many assets. That creates a dependency risk if the provider account, integration token, or scan path is compromised, mis-scoped, or left active after it is no longer needed.
Failure mechanism: The scanner typically operates through durable machine access, so weak scoping or delayed revocation can let an attacker or unauthorized process reuse the same access path for enumeration, data collection, or lateral movement into systems that were assumed to be read-only.
Impact: Exposure can include asset inventories, service metadata, security findings, and in some environments direct access to internal systems. Operationally, the organisation can lose confidence in scan integrity, incident scoping, and offboarding of the scanner itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Machine Identity Inventory | Hosted scanners rely on machine identities and service accounts for access. |
| NHI-02 — Secrets and Credential Management | Scanner access commonly depends on tokens, keys, or certificates. | |
| NHI-04 — Authorization and Least Privilege | The scanner’s access scope must stay tightly bounded to its task. | |
| Recommendation — Inventory scanner credentials and owned identities so you can review and revoke them quickly. Store scanner secrets centrally and rotate them on a defined schedule. Restrict scanner permissions to read-only actions and the minimum required resources. | ||
| CIS Controls v8 | 6 — Access Control Management | Hosted scanners need controlled account and permission lifecycle management. |
| 8 — Audit Log Management | Scanner activity should be visible to detect unexpected access or scope drift. | |
| Recommendation — Remove unused scanner access paths and enforce timely deprovisioning. Log scanner authentication and data-access events for review and alerting. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity and Access Management | Hosted scanning depends on authenticated machine-to-system access. |
| GV.PO-1 — Policy | Scanner scope and ownership need explicit policy treatment. | |
| DE.CM-1 — Monitoring | Unexpected scanner reach or use should be detectable through monitoring. | |
| Recommendation — Apply least-privilege identity controls to every scanner connection. Define policy for scanner ownership, approval, and scope changes. Monitor scanner sessions and flag access outside approved targets. | ||
Practitioner Guidance
Governance implication: Treat the hosted scanner as a non-human identity with an owner, a documented scope, and a defined revocation path. The key judgement is not whether the scanner is managed by a vendor, but whether its permissions are narrowly bounded and reviewable.
What to watch for: Broad discovery roles, shared credentials, and scan exceptions that expand over time. Those patterns usually indicate that the scanner has drifted from a bounded assessment tool into a general-purpose access channel.
Practitioner takeaway: If you cannot explain exactly what the hosted scanner can reach, what it can read, and how you would cut it off quickly, the deployment is too permissive for safe use.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
