Who is accountable when phishing-resistant authentication is required but not implemented?

Accountability usually sits with the identity, platform, and system owners together, because authentication is a shared control surface. In government programmes, the compliance obligation extends to the agency, its contractors, and any federated service provider that handles the access path. The programme owner must ensure the assurance level matches the use case.

Why This Matters for Security Teams

Phishing-resistant authentication is not just a stronger login method. It is a control that changes whether an attacker can replay stolen credentials, seed session hijacking, or bypass weak MFA enrollment paths. When it is required but not implemented, the gap is usually not a single technical failure. It is an ownership failure across identity, platform, and application teams, with compliance risk extending into contractors and federated service providers. NIST Cybersecurity Framework 2.0 frames this as a governance and protection issue, not a narrow login concern.

For NHI-heavy environments, the risk compounds because service accounts, API keys, and automation paths often sit outside the human authentication design that security teams focus on first. NHI Mgmt Group notes that 80% of identity breaches involve compromised non-human identities, and the same control gaps that weaken human auth often expose machine access too. That is why guidance on lifecycle control in the Ultimate Guide to NHIs matters here: authentication assurance only works when it is actually enforced across the access path.

In practice, many security teams encounter the missing control only after a phishing attempt or audit exception has already exposed the gap.

How It Works in Practice

Accountability should be assigned at the control owner level, not left abstractly to “the organisation.” The identity team typically owns the authentication standard, the platform team implements it in the access stack, and the application or service owner ensures the required assurance level is configured for the use case. If a federated login path or contractor-managed environment is involved, the shared responsibility extends outward to the provider that operates that path. NIST guidance on identity assurance and the NIST Cybersecurity Framework 2.0 both support this style of accountable control ownership.

Operationally, teams should map every privileged or sensitive access path to a required authentication method, then verify where phishing-resistant methods such as FIDO2 security keys, passkeys, or certificate-backed auth are actually enforced. This should include:

• Administrative access to cloud consoles, IAM portals, and privileged workstations
• Federated single sign-on paths used by employees, vendors, and contractors
• Break-glass and recovery workflows, which are often the weakest exception path
• Non-human access patterns where secrets, tokens, or certificates are substituted for interactive login

For NHIs, the issue is often not a “login” in the human sense, but whether the machine identity is protected with equivalent assurance, short-lived credentials, and strong provenance. The Ultimate Guide to NHIs highlights that visibility and rotation failures are still widespread, which means control enforcement must be checked continuously rather than assumed from policy. Current best practice is to treat phishing-resistant auth as a verifiable implementation requirement, with evidence tied to the system owner, not just a policy statement in a standards document.

These controls tend to break down when legacy applications depend on unsupported login flows because the exception is allowed to become the operating model.

Common Variations and Edge Cases

Tighter authentication requirements often increase rollout friction, so organisations must balance phishing resistance against legacy compatibility, user recovery, and third-party access constraints. That tradeoff is real, but it does not remove accountability; it only changes where exceptions must be documented and approved.

One common edge case is a federated environment where the relying party wants phishing-resistant auth, but the upstream identity provider cannot deliver it consistently. In that case, current guidance suggests the relying party still owns the assurance decision and should not treat the IdP claim as sufficient without verification. Another edge case is service-to-service access: there is no universal standard for this yet, but the practical expectation is that equivalent assurance must come from workload identity, certificate controls, or short-lived token issuance rather than human MFA.

The real-world failure mode is exception sprawl. A few “temporary” bypasses for admins, partners, or recovery paths can quietly defeat the entire control. The Schneider Electric credentials breach, documented by NHIMG, is a reminder that access control weaknesses rarely stay isolated; they spread across connected systems and shared identity paths. Security teams should therefore record who approved the exception, who owns the fix, and who must prove closure.

Related resources from NHI Mgmt Group

• Who is accountable when phishing-resistant authentication still leaves recovery gaps?
• Who is accountable when phishing-resistant authentication is inconsistent across systems?
• Who is accountable when phishing-resistant authentication is not broadly adopted?
• Who should be accountable for device and API authentication in healthcare programmes?