Accountability sits with identity, security, and business leaders together because the gap is both technical and behavioural. IAM owns the control design, security owns risk reduction, and the business owns the workflows that force users into insecure shortcuts. Frameworks such as the NIST Cybersecurity Framework help assign those responsibilities clearly.
Why This Matters for Security Teams
Phishing-resistant authentication is not just a technical upgrade. It is a control that only works when the organisation is willing to remove unsafe fallback paths, align access design to real workflows, and enforce adoption across people, process, and tooling. When that does not happen, users keep reaching for passwords, push prompts, shared accounts, or recovery flows that attackers already know how to abuse.
This is why accountability cannot sit in a single function. IAM may own the authentication pattern, but business owners often own the exceptions that keep legacy access alive, while security owns the risk decision to tolerate the gap. The governance question is therefore broader than login methods: it is about whether the organisation will actually make the secure path the easy path. The NIST Cybersecurity Framework 2.0 is useful here because it makes ownership, protection, and response responsibilities explicit rather than implied.
NHI Mgmt Group’s research shows how quickly identity weakness becomes breach material, including cases like the Schneider Electric credentials breach, where identity misuse became an operational risk rather than a narrow authentication issue. In practice, many security teams encounter accountability failures only after users have already been pushed into insecure workarounds.
How It Works in Practice
Accountability for weak adoption should be assigned across three layers: control ownership, risk ownership, and workflow ownership. IAM or identity engineering owns the technical standard for phishing-resistant methods such as FIDO2 passkeys or hardware-backed authenticators. Security leadership owns the risk decision to reduce or retire weaker factors. Business and application owners own the process changes required to remove friction that drives users back to less secure options.
That means the operational answer is not “deploy MFA and hope.” It is to define where phishing-resistant authentication is mandatory, where exceptions are allowed, who approves them, and when they expire. The best practice is evolving, but current guidance suggests phishing-resistant methods should be paired with conditional access, device trust, and step-up rules so the secure path is both enforced and practical. NIST’s identity guidance helps frame this as assurance, not just convenience, while the NHI Mgmt Group’s Ultimate Guide to NHIs shows the broader governance pattern: visibility, lifecycle control, and removal of standing access all matter when authentication is part of a larger trust model.
- Set a named control owner for phishing-resistant authentication.
- Require business owners to justify any exception, not just request it.
- Track adoption by population, application, and authentication path.
- Remove legacy recovery methods that bypass stronger authentication.
- Review help desk and reset workflows, since those are common bypass points.
Teams should also watch for indirect accountability failures, such as applications that still rely on passwords because of vendor limitations or service desk scripts that reset access without revalidating identity. These controls tend to break down when legacy systems, outsourced support, or emergency access procedures still depend on password-based recovery.
Common Variations and Edge Cases
Tighter phishing-resistant authentication often increases rollout cost and user friction, so organisations have to balance assurance against operational continuity. That tradeoff is real, especially in environments with contractors, frontline staff, or regulated customer portals where device ownership and browser support vary.
There is no universal standard for this yet on exactly how quickly every workforce segment should be moved to phishing-resistant methods, but current guidance suggests prioritising high-risk roles first, then expanding by application criticality. Public-facing admin access, privileged users, and finance workflows usually deserve the earliest enforcement. Shared terminals, call centres, and third-party access often need tailored patterns because a single authenticator model may not fit all users.
One important exception is recovery. If account recovery still relies on email links, SMS, or manual resets without strong verification, the organisation has left the back door open even after upgrading primary login. That is why accountability should extend to help desk owners and product owners, not only IAM. The broad lesson is simple: phishing-resistant authentication fails as a program when adoption is treated as a technical rollout instead of an accountable business control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Access control responsibility maps to who can approve and enforce stronger authentication. |
| NIST CSF 2.0 | GV.OV-1 | Governance oversight is needed when adoption gaps create accepted security risk. |
| NIST AI RMF | AI governance style accountability applies to organisational control ownership and oversight. |
Assign control owners for authentication policy and require documented approval for any weaker-access exception.
Related resources from NHI Mgmt Group
- Who is accountable when phishing-resistant authentication is inconsistent across systems?
- Which frameworks should guide phishing-resistant authentication decisions?
- Who should own the move to phishing-resistant authentication?
- Who is accountable when alternate login methods are left enabled after stronger authentication is deployed?
