What do organisations get wrong when they rely on certification alone to evaluate passwordless readiness?

Why This Matters for Security Teams

Passwordless certification can be a useful signal, but it is not a deployment verdict. A product may satisfy a standard on paper and still fail in the places that matter most: browser coverage, operating system constraints, legacy apps, mobile enrollment, recovery flows, and help desk operations. For security teams, the real risk is confusing a compliance artifact with operational readiness.

That mistake shows up fast when password fallback paths remain active, when developers avoid the control because it slows builds, or when users are forced back to shared secrets during exceptions. The gap is not academic. NHI Management Group research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is why passwordless should be evaluated as a replacement for brittle secret handling, not as a checkbox. See the Ultimate Guide to NHIs — What are Non-Human Identities for the broader governance context and the NIST Cybersecurity Framework 2.0 for a controls-based way to think about outcomes.

In practice, many security teams discover passwordless exceptions only after rollout friction has already pushed users back to passwords.

How It Works in Practice

Certification should be treated as the starting point for due diligence, not the end of it. The operational question is whether the authentication method works across the organisation’s real environment: supported browsers, endpoint management standards, mobile operating systems, VPN dependencies, CI/CD tooling, and the applications that still expect legacy session handling. A certified product may still be a poor fit if it depends on narrow platform features or if its recovery process is so brittle that service desk staff create insecure workarounds.

A practical evaluation usually includes four checks. First, test interoperability across the full application stack, including SaaS, internal web apps, and admin consoles. Second, validate enrollment and recovery for edge cases such as shared workstations, contractor devices, and lost-device events. Third, measure developer adoption and admin experience, because controls that slow software delivery or break automation tend to be bypassed. Fourth, verify that the policy model supports step-up authentication and conditional access rather than forcing one rigid workflow for every user and device.

For NHI and agentic environments, the same lesson applies to machine credentials: trust only certificates or standards claims that hold up under real workload conditions. The Sisense breach is a reminder that identity control failures often emerge where governance assumptions meet messy implementation. Best practice is to align certification evidence with architecture review, pilot telemetry, and rollback planning. These controls tend to break down in mixed endpoint estates with unmanaged browsers and legacy apps because the certified path is not the path users actually take.

Common Variations and Edge Cases

Tighter passwordless requirements often increase deployment overhead, requiring organisations to balance assurance against usability and support cost. That tradeoff matters most in environments with contractors, BYOD, shared terminals, or heavily regulated admin workflows, where the “right” control on paper may not survive daily operations.

Current guidance suggests separating three questions that are often mixed together: does the product conform to a standard, does the organisation support it end to end, and will people actually use it without creating exceptions? Certification can answer the first question, but it says little about federation quirks, browser policy conflicts, fallback to passwords, or whether recovery depends on the same weak processes the programme was meant to eliminate.

There is also no universal standard for how much interoperability evidence is enough. Security teams should therefore test passwordless readiness against their highest-friction applications, not their cleanest ones. In highly diverse estates, a control that looks strong in a lab can fail once identity providers, endpoint posture checks, and application session policies collide. That is why readiness assessments should combine vendor certification, architectural review, and a live pilot before any broad mandate.

Related resources from NHI Mgmt Group

• What do organisations get wrong when they rely on complaint volume alone?
• What do organisations get wrong when they treat SAML and SSO as the same control?
• What do organisations get wrong when they treat risk management as separate from framework adoption?
• What breaks when organisations rely on basic MFA alone for SOC 2 readiness?