Scan-based pricing charges only for the resources an organisation scans and only when those scans run. It is usually better for on-demand assessments, periodic compliance reviews, and GRC use cases where teams need flexibility rather than always-on monitoring across every asset.
Expanded Definition
Scan-based pricing is a consumption model in which an organisation pays only for scans that are executed and only for the resources included in those runs. In NHI and security operations contexts, that usually means paying per asset, per workload, per repository, or per assessment cycle rather than for continuous coverage. The model is common in GRC workflows, periodic control validation, and point-in-time assurance activities where the question is not “is everything watched all the time?” but “what must be checked now?”
Definitions vary across vendors, because some platforms describe pricing by object scanned, others by scan job, and others by consumed credits. The operational distinction is whether cost is tied to scan activity, not whether the scan is agentless, authenticated, or scheduled. That makes the concept adjacent to usage-based billing, but narrower in practice because it is specifically about security or compliance scanning rather than generic cloud consumption. For broader governance context, NIST Cybersecurity Framework 2.0 is useful for mapping why scan cadence matters to Identify, Protect, and Detect outcomes. The most common misapplication is treating scan-based pricing as if it were equivalent to full visibility, which occurs when teams assume a low-cost point-in-time scan program can substitute for continuous coverage of high-risk NHIs.
Examples and Use Cases
Implementing scan-based pricing rigorously often introduces a coverage tradeoff, requiring organisations to weigh lower spend against the risk that important assets go unscanned between scheduled runs.
- A GRC team runs quarterly scans of service accounts and API keys before audits, using a cost model that only charges when the scan job is executed.
- A cloud security team scans a subset of workloads after major releases, then expands the scan set only for systems with elevated privileges or customer data exposure.
- An internal control owner uses periodic checks to validate secrets hygiene against findings in the Ultimate Guide to NHIs, rather than paying for constant scanning of low-risk environments.
- A compliance lead aligns scheduled scans with NIST Cybersecurity Framework 2.0 review cycles so the organisation can evidence recurring control checks without committing to always-on monitoring.
- A security program with limited budget scans acquired applications first, then reserves broader coverage for systems where NHI sprawl or secrets exposure is most likely.
When used well, the model fits teams that need measurable assurance at defined intervals and can tolerate some delay between checks.
Why It Matters in NHI Security
Scan-based pricing matters because it can make the difference between having a repeatable assurance process and having no program at all, but it can also create blind spots if leaders confuse affordability with completeness. NHI risk is often hidden in service accounts, API keys, and machine-to-machine workflows, so the value of scanning depends on whether the right assets are selected and whether scan results are acted on quickly. NHI Mgmt Group reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which means point-in-time scanning can help surface exposure but cannot by itself prevent recurrence. The Ultimate Guide to NHIs also shows that only 5.7% of organisations have full visibility into their service accounts, reinforcing why scan scope and cadence matter.
In practice, teams should treat scan-based pricing as a governance decision, not just a procurement choice, because the billing model influences how often evidence is gathered, how wide coverage can be, and how quickly exceptions are found. Organisations typically encounter the real cost of under-scanning only after a secrets leak, at which point scan-based pricing becomes operationally unavoidable to address.
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 NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Ongoing monitoring outcomes depend on how often scans are run and what they cover. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Visibility and discovery issues for NHIs make scan scope a core governance concern. |
| NIST SP 800-63 | Identity assurance concepts inform how often machine identities and credentials should be checked. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero Trust requires continuous verification, which scan-based pricing may only partially support. |
| NIST AI RMF | GV.3 | Governance should define acceptable risk for periodic scanning versus continuous oversight. |
Use scans to inform access decisions, but do not let point-in-time checks replace continuous verification.
Related resources from NHI Mgmt Group
- How can organisations decide whether to move from seat-based to usage-based identity pricing?
- What do security teams get wrong about usage-based authorization pricing?
- How should security teams choose between a scan-based AD tool and continuous monitoring?
- What breaks when usage-based pricing discourages rotation and dynamic secrets?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
