Who is accountable for the exceptions in a passwordless rollout?

IAM, endpoint, and platform teams share accountability because the exceptions usually arise at the boundary between device support, application integration, and remote access design. Governance should require explicit ownership for every unsupported use case, so fallback methods do not become unmanaged permanent controls.

Why This Matters for Security Teams

Passwordless programmes rarely fail on the primary happy path. The harder problem is exception handling: legacy apps that cannot accept modern auth flows, devices that cannot meet posture requirements, and remote users who still need a recovery path. If those exceptions are not assigned to a named owner, they turn into standing access, undocumented bypasses, or repeated help desk overrides. That is an identity governance issue, not just an implementation detail.

Current guidance in the NIST Cybersecurity Framework 2.0 and NHIMG research both point to the same operational reality: controls must be owned, measured, and retired, especially where fallback methods exist. NHIMG’s Ultimate Guide to NHIs shows that 97% of NHIs carry excessive privileges, which is a useful warning for passwordless exceptions too, because exception paths often accumulate more access than intended.

In practice, many security teams encounter exception sprawl only after an audit, an outage, or a breach review has already exposed how many “temporary” workarounds became permanent controls.

How It Works in Practice

Accountability for passwordless exceptions should follow the control boundary, not the org chart. IAM usually owns policy, standards, and exception workflow. Endpoint teams own device supportability and posture enforcement. Platform or application owners own whether the application can support passkeys, SSO, conditional access, or alternate assurance paths. Security governance should require a named owner, expiry date, compensating control, and review cadence for every exception.

A strong exception process usually includes:

• Business justification tied to a specific application, device class, or user population
• Documented compensating control, such as step-up verification or restricted network access
• Time limit and automatic review before the exception expires
• Explicit approval from the accountable system owner, not just the IAM team
• Metrics on exception volume, age, and repeat requests

This approach aligns with the Ultimate Guide to NHIs because unmanaged fallback paths create the same governance problem seen with secrets and service accounts: access persists after the original reason for it has disappeared. Where passwordless is layered into a broader identity programme, the NIST Cybersecurity Framework 2.0 supports this by emphasizing accountable risk management and continuous oversight rather than one-time approval.

The practical rule is simple: if the exception changes the security model, the owner must be able to explain the risk, the compensating control, and the date it ends. These controls tend to break down when exceptions are handled informally for high-friction remote work scenarios because the review loop depends on manual follow-up that never happens.

Common Variations and Edge Cases

Tighter exception governance often increases rollout friction, requiring organisations to balance user experience against control quality. That tradeoff is real, especially during phased migrations where older applications, shared workstations, regulated user groups, or third-party support channels cannot move at the same pace as the rest of the estate.

There is no universal standard for every exception pattern yet. Best practice is evolving, but current guidance suggests treating each category differently rather than using one generic waiver process. For example, a legacy application exception may belong to the application owner, while a device compatibility exception may belong to the endpoint team. A remote-access exception may require joint approval from IAM and network security because the risk spans identity and session transport.

One common mistake is letting the help desk become the de facto exception owner. That creates operational convenience, but it also obscures accountability and makes it harder to retire compensating controls. Another edge case is emergency access. That path should be pre-approved, logged, time-limited, and reviewed after use, otherwise the exception becomes a permanent back door. The same governance discipline described in NHIMG’s research on NHI governance applies here: unmanaged exceptions are simply standing access by another name.

Related resources from NHI Mgmt Group

• Who is accountable when backup login methods remain enabled after passwordless rollout?
• Who remains accountable when a managed cloud security provider misses an incident?
• Who is accountable when multi-cloud access reviews miss excessive permissions?
• Who is accountable when unnecessary access remains in place?