Identity gaps in cloud auth show why phishing-resistant MFA matters

At a glance

What this is: The article argues that cloud identity gaps, especially weak or bypassable MFA, are enabling stolen-credential breaches and that x.509 certificates plus FIDO close the phishing-resistant authentication gap.

Why it matters: IAM, PAM, and NHI teams need to treat phishing resistance as a control design requirement, not an upgrade, because cloud access, demo accounts, and third-party exposure can all turn identity into the breach path.

By the numbers:

• IBM found a 71% rise in attacks using valid login credentials.
• 560 million Ticketmaster users' personal and payment details, nt details were exposed.

👉 Read Axiad's analysis of identity authentication gaps and phishing-resistant MFA

Context

Cloud identity controls fail when organisations treat authentication as a checkbox instead of a phishing-resistant control plane. This article focuses on how stolen credentials, weak MFA coverage, and third-party cloud access can turn ordinary account compromise into broad data exposure across customer environments.

The identity security issue is not simply whether MFA exists, but whether it can be bypassed, phished, or inconsistently enforced across accounts and applications. For IAM, NHI, and cloud security teams, the operational question is whether access is bound to a resistant factor or still depends on user behaviour that attackers can manipulate.

Key questions

Q: How should security teams reduce phishing risk in cloud authentication?

A: Start by removing reusable secrets and weak approval-based factors from the highest-risk access paths. Use phishing-resistant authentication for privileged, cloud, and third-party accounts first, then expand coverage to the rest of the estate. The key is to reduce the number of places where identity can be stolen through user interaction.

Q: Why do weak MFA deployments still lead to major breaches?

A: Weak MFA still leaves room for prompt fatigue, code interception, account reuse, and policy gaps across applications. Attackers do not need to break the factor if they can exploit the human workflow around it. In practice, the control fails when authentication is secure in theory but inconsistent in enforcement.

Q: What do organisations get wrong about certificate-based authentication?

A: They often assume certificates are just another login method, when they are really a way to bind identity to hardware-backed proof. The value is highest when the certificate replaces phishable credentials on sensitive access paths. If rollout is limited to a few systems, the residual attack surface remains large.

Q: How do teams decide where to use FIDO versus certificates?

A: Use FIDO where supported applications and devices can rely on passkeys without fallback to weaker factors, and use certificates where enterprise workflows or platform coverage are not yet complete. The decision should be based on coverage, compatibility, and risk, not preference. The objective is consistent phishing resistance across access paths.

Technical breakdown

Why standard MFA still leaves identity attack surface

Traditional MFA reduces risk, but it does not eliminate the human interaction layer that attackers target. If a user can be tricked into approving a prompt, entering a code, or reusing a weak factor across services, the control remains vulnerable to phishing and social engineering. The article’s core point is that identity attacks exploit the last mile of authentication, not just password quality. In cloud environments, that becomes especially dangerous when accounts are shared, under-reviewed, or outside central policy coverage.

Practical implication: map where MFA can be bypassed or phished, then prioritise replacement of those paths before expanding coverage elsewhere.

How x.509 certificates change authentication trust

x.509 certificates shift trust from user-entered secrets to device-backed credentials issued through PKI. The user still authenticates, but the proof of identity is tied to a private key stored in hardware and validated by the certificate chain, which makes credential capture far harder to weaponise through phishing. The article frames this as an approach that fits established workflows for endpoints and enterprise applications. That matters because security teams often need phishing resistance without redesigning every access path at once.

Practical implication: identify high-risk workforce and admin paths where certificate-backed authentication can replace password-based or prompt-based login.

Why FIDO passkeys help but do not close every gap alone

FIDO passkeys remove user-generated passwords from the login flow and use device-bound biometrics or local authentication to verify the user. That makes them strongly resistant to phishing, but the article correctly notes coverage gaps: not every destination supports FIDO yet, and device compatibility is still uneven. The architectural issue is partial adoption, not weakness in the standard itself. Teams therefore need to understand where FIDO can be the primary factor and where another resistant method still has to fill the gap.

Practical implication: inventory applications that cannot yet support FIDO and design a fallback that preserves phishing resistance, not convenience alone.

Threat narrative

Attacker objective: The attacker aims to convert valid login access into large-scale theft of cloud-hosted data and customer records.

1. Entry begins with stolen credentials or compromised access to a cloud account that lacks sufficiently strong phishing-resistant authentication.
2. Escalation occurs when attackers use that access to reach cloud-hosted systems and data stores protected by weak or incomplete MFA enforcement.
3. Impact follows as the attacker extracts customer or employee data at scale, turning one compromised identity into a broad breach footprint.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Phishing-resistant authentication is now an identity governance requirement, not an optional hardening step. The article’s central lesson is that cloud breaches increasingly begin with valid credentials rather than exotic exploitation. That shifts the control discussion from password strength to whether authentication can survive phishing, prompt abuse, and third-party exposure. Practitioners should treat resistant authentication as a baseline control for any account that can reach production or sensitive customer data.

x.509 and FIDO solve different parts of the same trust problem. x.509 certificates bind authentication to hardware-backed credentials and enterprise issuance, while FIDO removes reusable passwords and reduces user-entered secrets. The article is strongest when it shows why neither control should be treated as a universal substitute for the other. The practical conclusion is that identity programmes need a portfolio approach, not a single-factor modernisation project.

Identity attack surface expands fastest where governance is uneven across accounts, apps, and partners. The Snowflake, Ticketmaster, and Santander examples all point to the same structural weakness: controls are only as strong as their weakest authentication path. This is not just a breach problem, it is a lifecycle problem, because demo accounts, inherited access, and third-party entitlements often escape the strongest standards. Security teams should map where policy exceptions still create phishable access.

Phishing resistance should be measured as an enterprise state, not a feature rollout. An organisation can have MFA and still remain exposed if users, applications, or partner connections can fall back to weaker methods. That makes control verification, exception tracking, and application coverage the real governance metrics. Practitioners should ask where proof of identity is still negotiable at runtime.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
• For a broader identity view: Review Ultimate Guide to NHIs for governance patterns that help separate resistant authentication from brittle exception handling.

What this signals

Identity assurance now has to be designed as a coverage problem. Once organisations can no longer assume every account follows the same authentication standard, the programme becomes an exception-management exercise. That is especially true in cloud estates where demo accounts, partner access, and privileged consoles often drift away from the main policy set.

Phishing-resistant authentication should be treated as an architectural baseline for sensitive access. If a control can be bypassed by user action, it is not strong enough for the most exposed paths in the estate. Teams should expect more scrutiny of authentication coverage, fallback methods, and the evidence used to prove that high-risk identities are actually protected.

Control verification will matter as much as factor selection. A future-ready identity programme will need to show where certificates, passkeys, and other resistant methods are enforced, where they are unavailable, and which exceptions remain open. That is the difference between security intent and measurable assurance.

For practitioners

• Inventory phishable authentication paths Map all workforce, admin, and third-party access paths that still rely on passwords, OTPs, or push approvals. Prioritise systems that can reach customer data, cloud storage, or privileged consoles, because those are the highest-value paths attackers target first.
• Replace weak MFA on high-risk accounts Move the most sensitive accounts to phishing-resistant methods first, including hardware-backed certificate authentication and FIDO where supported. Do not wait for full estate migration before protecting privileged and cloud-adjacent access.
• Close third-party and demo-account gaps Review inherited, vendor, and demo accounts separately from employee accounts, because these paths are often excluded from central MFA policy. Revoke or rebind access where accounts can be used without resistant authentication.
• Track fallback methods as a control exception Maintain a register of applications and identities that still rely on weaker authentication because of platform constraints. Treat each exception as a temporary risk decision with an owner, expiry date, and remediation plan.

Key takeaways

• Cloud identity breaches increasingly begin with valid credentials, so authentication design is now a primary breach control.
• Phishing-resistant options such as x.509 and FIDO reduce exposure, but only if organisations close fallback paths and policy exceptions.
• Security teams should prioritise high-risk access paths first, especially privileged, cloud, and third-party accounts that attackers can target through identity.

Key terms

• Phishing-resistant authentication: Authentication that cannot be easily captured, replayed, or approved by a phishing attack. It uses controls such as hardware-backed certificates or FIDO passkeys so the proof of identity is tied to the device and not to a reusable secret entered by the user.
• x.509 certificate: A digital certificate used to bind an identity to a public key under a trusted certificate authority. In enterprise access, it is often backed by hardware and a PIN, which makes it harder for attackers to steal or reuse than passwords or one-time codes.
• FIDO passkey: A passwordless authentication credential that uses device-bound cryptographic keys and local user verification such as biometrics or PIN. It reduces phishing risk by removing reusable passwords from the login process and limiting what an attacker can capture in transit.
• Identity attack surface: All of the places where an attacker can attempt to compromise access through authentication, secrets, account recovery, or policy exceptions. In cloud programmes, the surface grows when accounts, applications, and partners do not share the same assurance standard.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Axiad: Identity Gaps: The Need to Use Both x.509 & FIDO. Read the original.