Should organisations move away from passwords for high-risk access?

Yes, especially for privileged, remote, and frequently targeted accounts. Passwordless or phishing-resistant authentication reduces the reuse value of stolen credentials and makes bulk password dumps less useful to attackers. Organisations should phase the change in where account takeover would cause the most damage.

Why This Matters for Security Teams

High-risk access is where password weaknesses become business risk. Privileged admins, remote operators, and service owners are prime targets because one stolen credential can lead to broad access, lateral movement, or credential harvesting. Passwordless and phishing-resistant methods reduce the reuse value of breached secrets, but the bigger point is that authentication should match the blast radius of the account, not the convenience of the workflow.

This is especially important where organisations still rely on long-lived secrets in code, CI/CD, or shared admin paths. NHIMG research shows that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which aligns with the operational reality documented in Ultimate Guide to NHIs. Security teams often focus on password complexity while attackers focus on token theft, session hijacking, and social engineering.

Current guidance from OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 points toward stronger identity assurance and reduced secret exposure, but implementation must be phased. In practice, many security teams discover the real weakness only after an admin mailbox, VPN profile, or API key has already been abused in a live incident.

How It Works in Practice

The practical move away from passwords is not just “turn on MFA.” For high-risk access, organisations should prioritise phishing-resistant authentication such as passkeys, hardware-backed credentials, certificate-based sign-in, or federated single sign-on with strong device assurance. The objective is to remove shared, reusable secrets wherever possible and replace them with cryptographic proof tied to the user, device, or workload.

For privileged access, this usually means combining passwordless login with just-in-time elevation, short-lived sessions, and step-up controls for sensitive actions. That is consistent with the broader NHI guidance in Ultimate Guide to NHIs — Key Challenges and Risks, which emphasizes lifecycle control, rotation, and minimizing standing access. Where secrets are still needed, they should be issued only when required, stored in managed systems, and revoked automatically after use.

• Use phishing-resistant sign-in for admins, remote access, and financial or production systems.
• Prefer passkeys, FIDO2 hardware keys, or certificate-backed authentication over passwords for interactive access.
• Pair authentication with device posture, location, and risk-based policy at request time.
• Replace permanent privilege with JIT elevation and session limits for sensitive tasks.
• Monitor for fallback paths such as recovery email, legacy VPN, or helpdesk resets.

For workflows involving non-human identities, the same principle applies even more strongly: use workload identity and short-lived tokens rather than shared passwords or static API secrets. These controls tend to break down in legacy environments with shared admin accounts, unsupported applications, or vendor integrations that still require password-based login because exception paths become the new attack surface.

Common Variations and Edge Cases

Tighter authentication often increases rollout cost, user friction, and dependency on modern identity infrastructure, so organisations must balance security gains against operational continuity. That tradeoff is most visible in legacy estates, emergency access scenarios, and third-party support models where passwordless coverage is incomplete.

There is no universal standard for every environment yet. Some systems cannot support passkeys or modern federation, and some break-glass accounts still require tightly controlled secrets. In those cases, best practice is to isolate the exception, put it behind compensating controls, and reduce its use to documented recovery events only. The more sensitive the system, the less acceptable it is to rely on a password as the primary factor.

Additional nuance appears in hybrid environments where humans and NHIs overlap. Password removal for people does not automatically solve service account risk, and long-lived secrets can persist even after user authentication is modernized. The 2024 ESG Report: Managing Non-Human Identities reinforces that compromised NHIs remain a common incident path, so password reduction should be treated as one part of a broader identity hardening programme, not a standalone fix.

For organisations aligning to NIST SP 800-53 Rev 5 Security and Privacy Controls, the practical test is simple: if an attacker steals the credential, how much can they do before detection and revocation? That question should guide which accounts move first.

Related resources from NHI Mgmt Group

• When should organisations treat an NHI as a high-priority risk?
• What breaks when organisations rely on passwords and OTPs for high-risk access?
• When does JIT access create more risk than it reduces?
• When should organisations treat machine access as a high-risk identity problem?