TL;DR: Identity-based cyberattacks are now the top global cybercrime attack vector, according to Axiad, with IBM cited in the article reporting a 71% rise in attacks using valid login credentials, while recent Snowflake-linked breaches showed how stolen credentials and weak MFA coverage can cascade into large-scale data loss. Conventional MFA is not enough when phishing and human bypass paths remain open.
At a glance
What this is: This is an identity-authentication analysis arguing that cloud access controls remain vulnerable when MFA is not phishing-resistant and credentials can be stolen or bypassed.
Why it matters: It matters because IAM teams need to decide when conventional MFA is insufficient and where certificate-based or passkey-based controls belong in cloud auth programmes.
By the numbers:
- IBM reported a 71% rise in attacks using valid login credentials.
Context
Cloud authentication is only as strong as the weakest factor path, and phishing-resistant MFA is the dividing line between a control that reduces friction and one that actually resists credential theft. This article focuses on identity gaps in cloud auth, especially where human approval, password reuse, or incomplete MFA rollout leaves cloud accounts exposed.
The source ties those gaps to recent breaches involving stolen credentials and then argues that x.509 certificates and FIDO passkeys close different parts of the gap. For IAM teams, the practical question is not whether MFA exists, but whether the authentication method can survive phishing, user bypass, and incomplete platform coverage.
Key questions
Q: How should security teams respond when attackers manipulate MFA in a cloud account takeover?
A: Security teams should treat MFA manipulation as a post compromise persistence tactic, not just an authentication issue. The immediate priority is to revoke malicious sessions, remove attacker added MFA methods, disable abused OAuth grants, and validate that no secondary access paths remain. Teams should also inspect audit logs for irregular sign-ins, automate remediation where possible, and reset trust in the affected account and adjacent resources.
Q: When should organisations prioritise x.509 certificates over passkeys for authentication?
A: Use x.509 certificates when you need broad enterprise coverage across managed devices, legacy applications, and workflows where passkeys are not yet consistently supported. Passkeys are strong for passwordless web access, but certificates fill the gaps where platform coverage and application compatibility are still uneven.
Q: What are the signs that cloud authentication is still too easy to phish?
A: Look for inconsistent MFA enforcement, exceptions on high-value accounts, user-approved push flows, legacy credential paths, and applications that accept weaker login methods alongside stronger ones. If an attacker can still turn a stolen credential into a valid cloud session, the authentication design is not yet phishing resistant.
Q: What is the difference between certificate-based authentication and FIDO in practice?
A: Certificate-based authentication is strongest where device-bound trust and managed issuance are needed, while FIDO is often better where supported applications and user experience matter most. Many enterprises need both. The decision is less about which method is better overall and more about which one fits the access path, platform, and assurance requirement.
Technical breakdown
Why conventional MFA still fails in cloud authentication
Multifactor authentication only blocks some compromise paths. If a factor can be phished, bypassed, or socially engineered, the attacker still gets a valid session. The article’s core point is that cloud environments expose a mismatch between policy intent and authentication reality: organisations may believe MFA is in place, yet users can circumvent it or encounter destinations where it is not consistently enforced. That leaves the cloud account protected by process assumptions rather than resistant authentication. In practice, the control gap is not just the presence of MFA, but whether the factor remains robust when the user, device, and application are all in play.
Practical implication: Treat MFA coverage as a control test, not a policy statement, and verify that every cloud access path is actually phishing resistant.
How x.509 certificates and FIDO split the phishing-resistant MFA problem
x.509 certificates and FIDO address different authentication gaps. x.509 certificates use PKI-backed hardware token plus PIN authentication and fit managed workstation and enterprise application access well, while FIDO passkeys remove passwords and rely on device-bound biometrics or similar local verification for web and app sign-in. The article’s practical distinction is important: FIDO alone does not yet cover every destination, while certificates cover legacy and managed workflows that passkeys may miss. That makes the problem one of control layering rather than product substitution.
Practical implication: Use certificates where you need broad enterprise coverage and FIDO where passwordless access can be enforced end to end.
Why stolen credentials become a cloud breach multiplier
Cloud breaches often begin with a small authentication weakness and expand because cloud access is shared across storage, apps, and partner workflows. Once an attacker lands with a valid credential, the issue is not only login, but the breadth of access that credential carries. The article uses Snowflake-linked incidents to show how a compromised account can expose large volumes of customer data when MFA is absent or weak. That pattern turns identity from a perimeter issue into a data-exposure amplifier, especially when account lifecycle, third-party access, and demo or service accounts are not tightly governed.
Practical implication: Map which cloud accounts can reach high-value data and make those accounts the first candidates for phishing-resistant controls.
Threat narrative
Attacker objective: Use a legitimate cloud identity to reach sensitive data at scale without triggering strong authentication barriers.
- Entry occurs through stolen credentials or phishing against accounts that are not protected by phishing-resistant MFA, giving the attacker a valid cloud login.
- Escalation follows when the compromised identity has access to cloud storage, demo environments, or shared data services that hold high-value customer records.
- Impact is achieved through bulk data theft from cloud-hosted systems, with the stolen access enabling large-scale customer exposure and downstream breach chaining.
Breaches seen in the wild
- 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.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
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
Phishing-resistant authentication is now a cloud governance requirement, not an advanced option: the article shows that conventional MFA still leaves exploitable human and process gaps in cloud access. When attackers can phish, bypass, or inherit weakly enforced factors, the control exists on paper but not in the access path. For identity programmes, that means authentication assurance must be measured by resistance to real attack paths, not by checkbox deployment.
Identity attack surface has become the primary control plane for cloud breach prevention: the article’s IBM reference and breach examples point to a simple reality. The first control boundary in cloud is no longer the network, it is the authenticity of the credential or factor used to get in. IAM teams that still treat MFA as a universal safeguard are underestimating how quickly valid credentials turn into data exposure.
x.509 and FIDO solve different halves of the same trust problem: one addresses managed, certificate-backed enterprise access, while the other removes passwords from web authentication. The important governance point is that neither replaces the need for policy consistency across applications, users, and device states. Practitioners should treat them as complementary authentication patterns, not interchangeable labels for stronger MFA.
Cloud breaches persist when identity assurance is separated from account governance: the incidents in the article involve more than weak login factors. Demo accounts, former-employee access, and third-party cloud data paths all show that authentication strength and lifecycle control must move together. For identity leaders, the real issue is whether a valid login should ever be enough to reach crown-jewel data in the first place.
What this signals
Phishing-resistant authentication is the governance threshold: teams should stop asking whether MFA exists and start asking whether the factor can survive phishing, user bypass, and partial deployment. That shift changes procurement, rollout sequencing, and exception handling across cloud apps.
The article’s core warning is that valid credentials remain a primary breach entry point when authentication is weaker than the attack. IAM programmes need to align assurance level, application criticality, and user population instead of applying one MFA pattern everywhere.
For practitioners
- Enforce phishing-resistant authentication for cloud admin and data-access accounts Prioritise certificate-based or passkey-based authentication on the accounts that can reach high-value cloud data, then remove fallback paths that still accept weaker factors.
- Inventory cloud accounts that still allow bypassable MFA Identify demo accounts, legacy logins, and exceptions where users can satisfy MFA through weaker or user-mediated methods, then classify those paths by data access scope.
- Separate broad cloud access from low-assurance identities Reduce the reach of former employee, contractor, and shared service access so that a single compromised credential cannot expose large datasets or tenant-wide resources.
- Test authentication coverage across every cloud application path Verify that the same high-assurance factor is enforced in all front doors, including SSO, direct application access, and privileged admin workflows.
Key takeaways
- Conventional MFA can reduce risk, but it does not eliminate phishing, bypass, or inconsistent enforcement across cloud access paths.
- The article links stolen credentials and weak MFA coverage to breaches that exposed large amounts of customer data.
- The practical response is to move the highest-risk cloud accounts to phishing-resistant authentication and tighten their access scope.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on authentication paths that still allow phishing and bypass in cloud access. |
| NHI-10 — Human Use of NHI | The article shows human-mediated MFA steps that attackers can exploit through phishing and social engineering. | |
| Recommendation — Replace bypassable cloud login factors with phishing-resistant authentication for high-value accounts. Remove human-mediated approval steps from critical cloud authentication flows. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Strong authentication only helps when access permissions are limited to what the account truly needs. |
| Recommendation — Align cloud account permissions with authentication strength and reduce access on sensitive identities. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The article describes credential theft leading to large-scale data theft from cloud systems. |
| Recommendation — Map stolen-credential attack paths to credential access and exfiltration detections in cloud monitoring. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle and exception handling are central to the breaches discussed. |
| Recommendation — Review cloud account lifecycle controls and remove stale or exception-based authentication paths. | ||
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.
- 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.
- Cloud authentication gap: A mismatch between the security assurance an organisation believes it has and the actual resistance of its login paths. In cloud environments, this often appears when MFA is present but can still be bypassed, inconsistently enforced, or unsupported on some applications.
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.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org