Why do organisations need different assurance levels for identity proofing and authentication?

Proofing and authentication solve different problems. Proofing answers whether the person is who they claim to be, while authentication confirms control of an account or credential. Separating them lets organisations tune assurance to the use case, limit unnecessary data collection, and preserve privacy without weakening control over sensitive systems and transactions.

Why This Matters for Security Teams

Different assurance levels are not administrative detail, they are the mechanism that keeps identity controls proportional to risk. NIST SP 800-63 Digital Identity Guidelines separates identity proofing from authentication because the confidence needed to enrol an identity is not the same as the confidence needed to let that identity sign in later. That distinction matters when organisations handle contractors, customers, admins, service accounts, or high-value transactions.

When teams collapse both steps into one blanket control, they often over-collect data, under-protect sensitive actions, or create friction where it is not needed. Strong proofing does not compensate for weak authentication, and strong authentication does not prove a person was correctly enrolled in the first place. NHIMG research on the Ultimate Guide to NHIs shows how quickly identity risk compounds when credentials, lifecycle controls, and governance are treated as the same problem, especially in environments with many machine identities. In practice, many security teams encounter the weakness only after a fraudulent enrolment, account takeover, or secrets leak has already created downstream access.

How It Works in Practice

Good identity programs assign different assurance levels to different decisions. Proofing sets the bar for how much confidence is required before creating an identity record or issuing an account. Authentication sets the bar for how confidently the system can confirm ongoing control of that identity at login, during step-up checks, or before a sensitive action. The practical goal is to match evidence and control strength to the transaction, not to force every user or workload through the highest possible bar.

In a mature model, proofing may involve government ID checks, workplace verification, or controlled registration workflows. Authentication may use passwords, phishing-resistant MFA, device-bound credentials, or cryptographic proof. For higher-risk actions, teams add step-up authentication rather than re-proofing the identity. This is why NIST SP 800-53 Rev. 5 Security and Privacy Controls and NIST SP 800-63 Digital Identity Guidelines are usually read together: one informs control selection, the other informs identity assurance.

• Use high-assurance proofing when account creation can unlock regulated data, privileged access, or legal commitments.
• Use stronger authentication for sessions that reach production systems, payment flows, or admin consoles.
• Keep proofing evidence separate from authentication factors so privacy collection stays limited.
• Reassess assurance when the transaction changes, not only when the user first enrols.

This distinction also matters for NHIs. Secrets, tokens, and certificates authenticate control, but they do not prove that a service was properly registered, governed, or scoped. NHIMG’s 52 NHI Breaches Analysis and Top 10 NHI Issues show that failures often begin with weak lifecycle discipline, not just weak sign-in controls. These controls tend to break down when legacy systems force a single shared identity path for onboarding, access, and privileged operations because the assurance model can no longer vary by risk.

Common Variations and Edge Cases

Tighter proofing often increases friction and data-handling overhead, requiring organisations to balance stronger enrolment confidence against privacy, cost, and user experience. That tradeoff is real, especially for low-risk consumer journeys or internal tools where heavy proofing can be disproportionate.

Current guidance suggests using different assurance levels by use case, but there is no universal standard for every organisation. Some sectors require formal identity proofing before issuance, while others rely on delegated trust, device posture, or existing enterprise identity records. The key question is whether the action being protected justifies the evidence being collected. For example, a routine portal login may only need moderate authentication assurance, while adding a bank account, changing tax data, or granting admin rights may require step-up controls.

Machine identities create a similar edge case. A service account is not a person, so “proofing” usually means verifying workload provenance, ownership, and configuration rather than checking a human document. In those cases, authentication should be bound to workload identity and short-lived credentials, not long-lived shared secrets. This is where organisations often need to distinguish policy for humans from policy for NHIs, because one-size assurance rules can over-protect low-risk activity and under-protect privileged automation.

Related resources from NHI Mgmt Group

• Why do flexible levels of identity assurance matter when a wallet is used across different services?
• What breaks when organisations rely on SMS codes and knowledge-based checks for identity assurance?
• When should organisations require higher identity assurance instead of relying on standard passwordless login?
• Who is accountable for identity assurance when organisations move from passwords to passwordless authentication?