Who is accountable when onboarding uses passwordless but the identity was never strongly proofed?

The accountable owners are the identity, security, and business leaders who approved the onboarding design and its assurance level. If the control model relies on passwordless alone, the programme has accepted a weaker trust boundary than the risk usually requires.

Why This Matters for Security Teams

passwordless onboarding often gets treated as a finished trust decision when it is only an authentication convenience. If the identity behind the session was never strongly proofed, the organisation may have reduced friction without actually increasing assurance. That gap matters because onboarding is where the trust anchor is established, and weak proofing can let the wrong person, bot, or outsourced operator inherit a legitimate identity path.

Current guidance aligns better with risk-based identity assurance than with “passwordless equals secure” assumptions. The question is not whether a password was removed, but whether the person or workload was validated to the right assurance level before access was granted. NIST’s NIST Cybersecurity Framework 2.0 pushes organisations to make accountability and governance explicit, while NHIMG’s Ultimate Guide to NHIs shows how weak identity controls routinely turn into downstream exposure.

This is especially important in environments where onboarding is delegated to HR flows, vendor portals, or automated provisioning without a matching proofing step. In practice, many security teams discover the assurance gap only after a privileged account has already been used for access, not during the design review that approved passwordless onboarding.

How It Works in Practice

Accountability starts with the control owner who approved the identity lifecycle design, then extends to the security function that defined the assurance standard, and the business owner that accepted the risk. Passwordless authentication only proves possession of a device, passkey, or token at sign-in. It does not, by itself, prove that the identity was strongly proofed at registration.

Practitioners should separate three decisions:

• Identity proofing: how the subject’s identity was validated before enrolment.

• Authentication method: how the subject proves control during login.

• Authorisation scope: what access the subject receives after onboarding.

If onboarding is high risk, the proofing standard should be explicit and documented, with step-up checks for high-value accounts, contractor identities, or delegated admin access. Where the subject is a workload rather than a human, the trust model changes again: workload identity, short-lived credentials, and policy enforcement at runtime become more important than any one login method. That is why NHIMG’s Top 10 NHI Issues emphasises lifecycle control, and why NIST CSF 2.0 is useful for tying onboarding assurance back to governance and access accountability.

Strong practice usually includes documented proofing evidence, approval trails, periodic recertification, and revocation paths if the initial enrolment was too weak. Passwordless can still be part of a secure design, but only when it sits on top of a trust boundary that was properly established first. These controls tend to break down when onboarding is automated at scale across contractors, service providers, or cross-domain identity federation because the original proofing evidence is thin or never retained.

Common Variations and Edge Cases

Tighter proofing often increases onboarding friction, requiring organisations to balance assurance against user experience and operational speed. That tradeoff is real, but it does not remove accountability when the risk is high.

There is no universal standard for every workforce scenario yet. Best practice is evolving, especially for remote hiring, delegated enrollment, and identity proofing by third parties. In lower-risk environments, a lighter proofing path may be acceptable if access is tightly limited and reviewed more often. In higher-risk environments, such as admin onboarding, finance systems, or privileged vendor access, weak proofing should be treated as a design defect rather than a minor process issue.

Edge cases also appear when an organisation inherits identities from mergers, outsources onboarding, or uses self-service registration with passive checks only. In those situations, accountability cannot be shifted to the authentication vendor or the passkey provider. The accountable leaders are still the ones who accepted the assurance level and allowed it to govern access. NHIMG’s 52 NHI Breaches Analysis reinforces the pattern: weak identity assurance becomes visible only after misuse, not during sign-up.

Where strong proofing is missing, the most defensible response is to reclassify the identity, reduce privileges, and re-onboard it under a higher assurance standard rather than pretending passwordless alone closed the gap.

Related resources from NHI Mgmt Group

• Who is accountable when DNS weaknesses disrupt access to identity services?
• Who is accountable when cloud identity gaps lead to audit findings or breaches?
• Who is accountable when identity fraud succeeds through weak verification?
• Who is accountable when identity-service vulnerabilities are exploited in hybrid environments?