Authentication, authorisation and identity proofing explained

At a glance

What this is: This is a primer on identity proofing, authentication and authorisation, with the central finding that access only works when each step is completed in sequence.

Why it matters: It matters because IAM, PAM and lifecycle teams must treat these controls as separate governance stages for both human access and non-human identities.

👉 Read Imprivata's explanation of authentication, authorisation and identity proofing

Context

Authentication, authorisation and identity proofing are often discussed together, but they solve different problems. Identity proofing establishes who or what is presenting itself, authentication checks whether the presented evidence is credible, and authorisation decides what that identity can do once trust has been established.

For IAM practitioners, the operational issue is not the terminology itself but the control boundary between each stage. When organisations blur those boundaries, they create avoidable access risk across human users, privileged accounts and other non-human identities that depend on the same governance model.

Key questions

Q: How should security teams separate authentication from authorisation in IAM policy?

A: Security teams should treat authentication as proof that an identity is credible and authorisation as the policy decision that follows. Keep the controls separate in design, logging and ownership so that a strong login does not hide excessive privilege. This separation makes recertification, PAM and access review more accurate and easier to audit.

Q: Why do strong login controls still leave access risk unresolved?

A: Strong login controls only reduce the chance of unauthorised entry. They do not by themselves limit what a confirmed identity can reach, how long it can stay active, or whether stale entitlements remain in place. Access risk is resolved only when authentication, authorisation and lifecycle controls work together.

Q: What breaks when service accounts are governed like human logins?

A: What breaks is the lifecycle model. Service accounts do not behave like people, so human-style login assumptions miss rotation, offboarding and standing privilege risk. The result is a hidden access layer that may remain valid long after the original business need has ended.

Q: How can organisations tell whether zero trust is working for machine identities?

A: They should look for continuous re-evaluation of identity, context and access scope, not just a hardened sign-in event. If tokens, certificates or service accounts stay valid without review, zero trust is only partially implemented. Effective programmes show short-lived access, clear revocation paths and audit evidence for every entitlement.

Technical breakdown

Identity proofing versus authentication in access control

Identity proofing is the act of establishing an identity claim before access begins, while authentication is the system’s verification of that claim at login or entry time. In practice, a password, badge, token or biometric signal can support authentication, but each factor has different assurance strength and failure modes. A weak proofing step weakens every downstream decision because the system is only authenticating a claim, not reality. Multi-factor authentication raises assurance by combining independent evidence, but it still depends on the quality of the original identity record and enrolment process.

Practical implication: separate enrolment assurance from login assurance and review both when you assess access risk.

Authorisation is the policy layer that follows verified identity

Authorisation begins only after authentication succeeds. It answers a narrower question than authentication: what actions, data and systems should this identity be allowed to reach? That means role design, least privilege and privileged access governance belong in the authorisation layer, not the login layer. In hospital-like environments, for example, a confirmed clinician still should not inherit access to every system simply because the identity is valid. If policy is too broad, the access model turns identity assurance into a false sense of safety.

Practical implication: map every verified identity to specific entitlements and recertify those entitlements on a scheduled basis.

Why MFA and zero trust only work when access is continuously constrained

Multi-factor authentication reduces account takeover risk, but it does not replace authorisation or lifecycle control. Zero trust assumes no access is trusted by default, so the platform must continuously verify the identity, the device or workload, and the context of the request. That matters for service accounts, API tokens and other NHIs because they also need clear proof, bounded privilege and timely revocation. A strong login process with weak downstream governance still leaves a large attack surface if credentials remain valid longer than necessary.

Practical implication: pair MFA with entitlement minimisation, secret rotation and offboarding controls for both users and machine identities.

NHI Mgmt Group analysis

Identity proofing, authentication and authorisation are separate control problems, not synonyms. Organisations that collapse them into one governance bucket usually overestimate assurance at the front door and under-control privilege at the back end. The discipline is to treat identity evidence, login verification and entitlement assignment as distinct decisions with different owners and audit trails. Practitioners should preserve that separation in both IAM design and access review.

Authorisation is where most identity governance failures become operationally visible. A valid identity can still create excessive risk if role design is broad, privileged access is persistent or lifecycle controls do not remove stale entitlements. This is where PAM and recertification matter most because the access model, not the authentication method, determines blast radius. Practitioners should audit whether confirmed identities are being given more access than their task actually requires.

Zero trust loses its meaning if authentication is treated as a one-time event. The model only works when trust is continuously re-evaluated across session, device and request context, including for machine identities that never log in like a human. That makes downstream controls such as secret rotation, session scoping and access revocation part of the same governance chain. Practitioners should align policy enforcement with the actual lifetime of access, not with the initial login event.

Non-human identities make the same governance model harder, not different. Service accounts, tokens and certificates still require proof, verification and authorisation, but their lifecycle is more hidden and their access is often broader than a human user's. That creates a governance gap when teams focus only on interactive authentication and ignore standing machine privilege. Practitioners should extend identity controls across human and machine programmes instead of maintaining two disconnected rule sets.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For the broader governance baseline, see Ultimate Guide to NHIs - What are Non-Human Identities for the full identity scope.

What this signals

Identity control boundaries will matter more as organisations unify human and machine access programmes. Teams that keep proofing, authentication and authorisation in separate control families will find it easier to scale policy across people, service accounts and tokens without weakening auditability. The practical test is whether your programme can explain, in one view, who was verified, what was authorised and when that access expired.

The biggest failure mode is not a missing login method but a collapsed governance chain. If access reviews only see human users, machine identities can accumulate broad privilege outside the review cycle, and the result is silent risk growth that looks like normal operations until it does not.

For practitioners

• Separate proofing, authentication and authorisation in policy Document each stage as a distinct control with its own owner, evidence source and review cadence. Do not let a strong login process substitute for entitlement governance.
• Tighten privilege after identity is verified Review roles, group memberships and PAM assignments immediately after authentication design changes. Remove broad default access and align entitlements to the smallest practical task scope.
• Apply the same lifecycle discipline to machine identities Track service accounts, API tokens and certificates through enrolment, usage, rotation and revocation. Treat stale machine credentials as a governance defect rather than a tooling issue.
• Use zero trust as a continuous verification model Check whether your access policy re-evaluates identity, device and context during the session, not only at sign-in. Where it does not, add compensating controls for session scoping and step-up checks.

Key takeaways

• Authentication, authorisation and identity proofing are different controls, and mixing them creates blind spots in access governance.
• Machine identities inherit the same governance problem as human users when privilege, rotation and revocation are not managed together.
• Zero trust only works when access is continuously constrained, not when trust is established once at sign-in.

Key terms

• Identity Proofing: Identity proofing is the process of establishing that an identity claim is credible before access is granted. It usually happens before login and may rely on documents, enrolment checks, trusted records or other evidence that ties the claimant to a known identity.
• Authentication: Authentication is the verification step that tests whether a presented identity claim is genuine. It uses one or more factors such as a password, token, biometric signal or certificate to decide whether the claimant should be treated as the expected identity.
• Authorisation: Authorisation is the policy decision that determines what a verified identity can do after authentication succeeds. It controls access to data, systems and functions through roles, rules, privilege boundaries and lifecycle checks, not through login evidence alone.
• Non-Human Identity: A non-human identity is any machine or software identity used to authenticate and receive access, including service accounts, API keys, tokens, certificates and workload identities. It needs the same governance discipline as a human identity, but its lifecycle, privilege shape and revocation path are usually more opaque.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or IAM programme maturity, it is worth exploring.

This post draws on content published by Imprivata: authentication, authorisation and identity proofing explained. Read the original.