Should organisations use the same authentication method for all users and use cases?

Why This Matters for Security Teams

Using one authentication method for every user and use case sounds simpler, but it usually creates hidden risk. Authentication should match the assurance level needed for the action, not just the user category. High-risk scenarios such as admin access, remote access, and sensitive data operations need stronger phishing-resistant assurance, while lower-risk workflows may justify different controls. NIST’s control model in NIST SP 800-53 Rev 5 Security and Privacy Controls supports that risk-based approach.

The problem with a one-method policy is that it often forces security teams into two bad outcomes: over-securing low-risk tasks in ways users work around, or under-securing high-risk tasks with exceptions that become permanent. NHIMG research shows the same governance pattern in non-human identity environments, where fragmented controls leave organisations exposed. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a reminder that identity control fails when the baseline is inconsistent.

In practice, many security teams encounter authentication sprawl only after a privileged account, service account, or remote-access path has already become the easiest route into the environment.

How It Works in Practice

The better model is to standardise on an assurance baseline, then vary the factor or form factor based on risk, context, and user population. For example, the same phishing-resistant standard can be met with FIDO2 security keys, passkeys, or certificate-backed authentication where policy and device posture allow it. What matters is that the assurance outcome is consistent for equivalent risk, not that every user taps the same branded product.

This approach works best when identity policy is tied to use case and trust conditions. A remote administrator, a finance approver, and a contractor accessing a low-sensitivity portal should not all be handled the same way. Current guidance suggests mapping authentication strength to application sensitivity, device trust, network location, and session purpose. For NHI-adjacent workflows, the same logic applies to secrets, tokens, and service identities: access should be issued only when needed and revoked when the task ends. NHIMG’s Ultimate Guide to NHIs highlights how often organisations fail at this lifecycle discipline, and that failure often starts with inconsistent access rules.

• Define one enterprise assurance baseline for each risk tier.
• Use phishing-resistant methods for privileged, sensitive, and remote access.
• Allow different authenticators only when the assurance outcome is equivalent.
• Review exceptions frequently so temporary accommodations do not become permanent drift.

Where standards and operations intersect, ISO/IEC 27001:2022 Information Security Management supports consistent control governance, while Twitter Source Code Breach remains a useful reminder that weak or inconsistent access pathways can turn a single identity failure into broad organisational exposure. These controls tend to break down when legacy applications cannot support modern phishing-resistant methods because exception handling becomes the default operating model.

Common Variations and Edge Cases

Tighter authentication policy often increases friction, support load, and integration cost, requiring organisations to balance stronger assurance against legacy constraints. That tradeoff is real, especially in mixed estates where older systems cannot support modern protocols or where contractors, partners, and break-glass access need separate handling.

Best practice is evolving, but current guidance is clear on one point: exceptions should be limited, documented, and tied to compensating controls. For example, a legacy application may not support passkeys, but that does not justify weaker access everywhere else. Instead, organisations can isolate the legacy path, add session controls, and require stronger authentication at the nearest feasible trust boundary. For non-human identities, the same principle applies to API keys and service accounts, where the risk is not the login method itself but the lack of consistent lifecycle control. The Ultimate Guide to NHIs is especially relevant here because it shows how often organisations underestimate the operational cost of inconsistent identity governance.

The practical rule is simple: use different methods when needed, but do not use different assurance standards for the same risk. In mature environments, that distinction is what prevents policy fragmentation from becoming an attack surface.

Related resources from NHI Mgmt Group

• Should organisations use the same identity controls for internal agents and customer authentication?
• Should organisations use browser isolation for all privileged access?
• When should organisations use advanced protection modes instead of standard passkey choice?
• What should organisations prioritise when moving to service-based authentication models?