Identity attack surface gaps show why x.509 and FIDO both matter

At a glance

What this is: This article argues that modern identity attack surface reduction requires both x.509 certificates and FIDO because MFA alone does not reliably stop phishing, credential reuse, or cloud account abuse.

Why it matters: IAM and PAM teams should read this as a signal that phishing-resistant authentication has to be designed around coverage gaps, user workflow, and service access, not just policy enforcement.

By the numbers:

• IBM reported a 71% rise in attacks using valid login credentials.

Context

The security gap here is not authentication in the abstract. It is the mismatch between today’s cloud access paths and the controls many organisations still rely on, especially when identities can be reused, phished, or bypassed through unmanaged accounts.

In practical terms, the article is about identity attack surface management: reducing the number of ways an attacker can authenticate, replay access, or exploit weak account protection. That puts NHI governance, human authentication, and access policy design into the same control conversation.

The article’s examples are typical of a broader enterprise problem rather than an edge case. Cloud adoption expands the number of identities and access paths, while inconsistent MFA coverage leaves the weakest link visible to attackers.

Key questions

Q: What breaks when MFA is configured with weak, phishable factors?

A: Weak factors such as SMS codes, OTP apps, or push-based approvals can satisfy a policy checkbox while still leaving the environment open to phishing, man-in-the-middle, and push bombing attacks. That means the control may look compliant but fail under real attack conditions. Teams should test whether the factor actually binds the login to the user and target service.

Q: Why do valid credentials still drive major cloud breaches?

A: Valid credentials work because they look legitimate to the access layer. When attackers obtain usable login material, they often bypass perimeter controls, create trusted sessions, and move directly to data-rich systems. The risk grows when identities are reused, poorly monitored, or protected by authentication methods that can be phished or replayed.

Q: What do security teams get wrong about passwordless authentication?

A: The most common mistake is treating passwordless as a user-experience upgrade instead of an identity control change. Teams often focus on the login screen and ignore recovery, lifecycle governance, and fallback authentication, which is where many of the real risks emerge.

Q: How should organisations combine x.509 certificates and FIDO?

A: Use them as complementary controls, not competing ones. Certificates fit managed enterprise access where device trust and workflow stability matter, while FIDO is ideal for eliminating passwords where platform support is available. The right model is coverage-based, with each method filling the other’s gaps.

Technical breakdown

Why MFA alone fails against identity attack surface abuse

MFA is only as strong as the path an attacker uses to satisfy or bypass it. If a workflow still allows password entry, push approval fatigue, stolen session material, or a non-MFA-protected account, the control can be sidestepped without breaking authentication itself. The core issue is not whether MFA exists, but whether it is phishing-resistant and consistently enforced across all access paths, including third-party and legacy accounts. In cloud environments, identity attack surface grows when different services and user groups are protected unevenly. Practical implication: treat MFA coverage as a control inventory problem, not a checkbox.

Practical implication: inventory every access path and verify that each one is protected by phishing-resistant authentication, not just nominal MFA.

How x.509 certificates change phishing resistance for enterprise access

x.509 certificates bind authentication to a certificate-backed trust chain rather than a user-entered secret. In the model described here, a hardware token and PIN create a stronger possession-plus-knowledge factor that is much harder to phish than passwords or one-time codes. This matters because certificate-based authentication fits managed endpoints and enterprise workflows where durable device trust is acceptable. It is not a universal replacement for all use cases, but it does reduce attack surface where phishing and credential replay are most likely. Practical implication: use certificate-based authentication where managed devices and controlled apps make the trust model viable.

Practical implication: deploy certificate-based authentication for managed endpoints and sensitive enterprise applications where phishing resistance is the priority.

Why FIDO passkeys still need a complement in real environments

FIDO passkeys remove the human-generated password from the equation and can strongly reduce phishing risk. But the article is right to note that passkeys are not yet universal across every destination, platform, or device population. That means organisations that treat FIDO as a complete answer can leave coverage gaps wherever a destination does not support it or where device enrolment is inconsistent. The real design challenge is coverage, not just strength. Practical implication: pair FIDO with a fallback control that preserves phishing resistance where passkey support is incomplete.

Practical implication: use FIDO where support is mature, but define a secondary phishing-resistant path for destinations and devices that cannot use passkeys.

Threat narrative

Attacker objective: The attacker aims to use legitimate-looking identity access to reach cloud data and steal information at scale without triggering obvious authentication failure.

1. Entry occurs through stolen credentials, phishing, or access to a weak account that does not enforce phishing-resistant authentication.
2. Credential abuse follows when valid login credentials or legacy authentication paths let the attacker sign in as a legitimate user.
3. Impact comes from cloud access that allows data theft at scale, including customer records, payment details, and downstream account exposure.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Co-op cyber attack 2025: Attackers linked to Scattered Spider tricked their way into a Co-op employee account and stole personal data of all 6.5 million members.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity attack surface is now an authentication design problem, not a policy problem: The article shows that the real gap is not the presence of MFA, but the unevenness of its deployment and the number of alternate entry paths still available. If a cloud environment allows phishable authentication, third-party accounts, or legacy access to remain in circulation, the attack surface is already too broad. Practitioners should treat authentication architecture as part of identity attack surface management, not as a standalone login control.

x.509 and FIDO solve different halves of the same trust problem: Certificate-based authentication is strongest where managed devices, enterprise applications, and stable trust chains matter. FIDO passkeys are strongest where password removal and user convenience reduce phishing exposure. Neither on its own eliminates all coverage gaps, which is why the article’s central point is architectural, not product-specific. The implication is that identity programmes need layered phishing resistance rather than a single preferred method.

Phishing resistance is only meaningful when coverage extends to third-party and legacy identities: The Snowflake and related breach examples highlight that attackers do not need to defeat the strongest account if the weakest one remains reachable. That means demo accounts, vendor-linked access, dormant credentials, and unsupported destinations become the real governance problem. The discipline here is not just stronger authentication, but eliminating uncontrolled exceptions that re-expand the attack surface.

Identity attack surface reduction should be measured by failure paths, not feature adoption: A programme can report high MFA adoption and still leave critical access exposed if some paths remain phishable or unenforced. The better question is whether any high-risk identity can still authenticate through a method that depends on human judgement or reusable secrets. That shifts the control objective from adoption metrics to breach-resistant coverage.

Named concept: authentication coverage gap: The article exposes the gap between “we have MFA” and “every meaningful access path is actually phishing-resistant.” That gap is where identity-based attacks keep succeeding, because coverage shortfalls matter more than the presence of a strong control in one part of the environment. Practitioners should treat incomplete coverage as a control failure in its own right.

What this signals

Authentication coverage gap: Most identity programmes still report control adoption rather than control completeness, which leaves unsupported destinations, third-party accounts, and legacy logins outside phishing-resistant protection. The practical test is whether any high-risk access path can still be reached with a reusable secret or a human-mediated factor.

Organisations should now think of identity attack surface reduction as a coverage programme. That means mapping the places where passwords, one-time codes, or bypassable MFA remain in use, then deciding where x.509, FIDO, or another phishing-resistant method is actually enforceable.

For practitioners

• Map authentication coverage by access path Inventory every user, third-party, and service access path and record whether it is protected by phishing-resistant authentication or still depends on a phishable fallback.
• Prioritise non-MFA cloud accounts for remediation Find cloud and demo accounts that can still authenticate without phishing-resistant controls and move them into the highest-risk remediation queue.
• Deploy x.509 certificates where managed trust exists Use certificate-backed authentication for managed endpoints and sensitive enterprise applications where device control and operational consistency make the model sustainable.
• Use FIDO as the default passwordless path Apply passkeys wherever platform and destination support is mature, and document the exceptions that still need an alternate phishing-resistant route.

Key takeaways

• Identity-based attacks keep succeeding because the real control failure is incomplete coverage, not the absence of MFA as a policy.
• The article’s examples show that cloud breaches can scale quickly when stolen credentials or weakly protected accounts provide access to data-rich systems.
• Practitioners should treat phishing-resistant authentication as an architecture decision, combining x.509 and FIDO where each is operationally strongest.

Key terms

• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Identity Attack Surface: Identity attack surface is the total set of accounts, tokens, login endpoints, trust paths, and supporting systems that can be probed for access. For password spraying, the risk grows with every externally reachable authentication path and every dormant or weakly protected identity.
• X.509 Client Authentication: A certificate-based login method that lets MongoDB verify the identity of a connecting user or application. The client presents a certificate signed by a trusted certificate authority, and MongoDB maps the certificate subject to a database identity before allowing the connection.
• FIDO passkey: A passwordless authentication credential based on the FIDO standard. It uses cryptographic keys stored on a user device and often biometric confirmation to verify the user, reducing dependence on secrets that can be phished, reused, or guessed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.