Levels of Assurance describe how strongly an identity was verified before access is granted. Lower levels rely on weaker registration and authentication, while higher levels require stronger identity proofing and authentication controls. The concept helps organisations match identity confidence to risk, service sensitivity, and regulatory expectations.
Expanded Definition
Levels of Assurance, often abbreviated as LoA, express the degree of confidence an organisation can place in an identity claim after proofing and authentication. In NHI security, the same idea applies to service accounts, API keys, certificates, workload identities, and agent identities, even though NIST SP 800-63 Digital Identity Guidelines were originally written for human-facing identity assurance. In practice, LoA is not a single control but a risk signal that links identity proofing strength, credential quality, binding method, and the consequences of misuse.
Definitions vary across vendors and implementation teams. Some use LoA to describe initial registration confidence, while others fold in ongoing authentication strength, recovery workflows, and re-verification after lifecycle events. For NHIs, the useful question is whether the identity was established with enough rigour for the workload, API, or automated action it will perform. A token created through weak onboarding does not suddenly become high assurance because it is stored in a vault. The most common misapplication is treating possession of a secret as a high assurance identity, which occurs when credential storage is confused with identity proofing strength.
Examples and Use Cases
Implementing Levels of Assurance rigorously often introduces onboarding friction and operational overhead, requiring organisations to weigh stronger identity confidence against faster service activation and easier automation.
- A production service account that can deploy code to customer-facing systems is issued only after controlled registration, dual approval, and certificate-based authentication, rather than a manually generated API key.
- An internal batch workload is allowed lower assurance because it reads non-sensitive telemetry, but its entitlements are restricted and time-bound to reduce blast radius.
- An agent that can call external tools is assigned a higher assurance threshold, with identity proofing, attestation, and short-lived credentials aligned to the action scope.
- Teams map onboarding and reproofing rules to guidance in the Ultimate Guide to NHIs and compare those controls with the assurance concepts in NIST SP 800-63 Digital Identity Guidelines.
- A third-party integration is granted a lower initial level of assurance until the vendor proves key custody, rotation, and revocation discipline across the connection lifecycle.
For broader context on how assurance gaps show up in real NHI environments, the Ultimate Guide to NHIs highlights why unmanaged credentials often outlive the systems that created them.
Why It Matters in NHI Security
Levels of Assurance matter because NHI compromise is rarely about a single password event; it is about whether the identity was trusted too early, too broadly, or for too long. When assurance is weak, organisations often over-grant access to automation, pipelines, and agents that operate faster than human review can contain. That increases the chance of lateral movement, secrets abuse, and privileged misuse across production systems. Stronger assurance does not eliminate risk, but it narrows the set of identities that can legitimately perform sensitive actions and makes governance decisions auditable.
This is especially important given NHIMG research showing that 80% of identity breaches involved compromised non-human identities, which means assurance gaps can become a direct breach path rather than a theoretical concern. NHI assurance also supports zero trust by ensuring trust decisions are based on verified identity strength, not network location or convenience alone. Organisations typically encounter the cost of poor assurance only after an incident review reveals that a low-confidence identity was allowed to perform high-impact actions, at which point Levels of Assurance 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 and CSA MAESTRO address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL/AAL/FAL | Defines identity assurance, authentication, and federation assurance concepts central to LoA. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Assurance depends on how strongly an NHI is established and bound to its credentials. |
| NIST CSF 2.0 | PR.AC-1 | Access is governed by verified identity and credential strength, which LoA operationalises. |
| NIST Zero Trust (SP 800-207) | Zero Trust depends on continuously evaluating trust signals, including identity assurance. | |
| CSA MAESTRO | Agentic systems need assurance boundaries before tool access and autonomous execution. |
Set NHI proofing and authentication strength to the assurance level required by the workload's risk.
Related resources from NHI Mgmt Group
- How should security teams set assurance levels in digital onboarding?
- Who is accountable when a passwordless rollout fails to meet required identity assurance levels?
- How should teams reduce Oracle ERP assurance costs without weakening controls?
- What is the difference between IP reputation and identity assurance?
