Identity breaches surge as passwordless progress stalls in Japan

At a glance

What this is: RSA’s 2026 ID IQ Report shows identity breaches rising sharply while passwordless adoption continues to stall, especially in Japan.

Why it matters: This matters because IAM teams have to treat identity as an operational risk surface spanning human authentication, privileged access, and machine identity controls.

By the numbers:

• 69% of global organizations experienced an identity-related breach in the last three years.
• 45% of organizations said the cost of an identity-related breach exceeded the typical cost of a breach as defined by IBM.
• 90% of organizations reported challenges in moving toward passwordless authentication.
• 57% still don’t use passwordless as their primary authentication method.

👉 Read RSA Security's 2026 ID IQ Report on identity breaches and passwordless adoption

Context

Identity breach frequency and breach cost are rising together, which means the problem is no longer limited to authentication friction or isolated account compromise. For IAM leaders, the signal is broader: control gaps across login, help desk recovery, privileged access, and identity lifecycle now compound into business impact.

The report also shows that passwordless adoption is still running into operational and behavioural blockers. That matters for human identity programmes, but the same lesson extends to NHI and autonomous access: if identity controls remain easier to bypass or harder to govern than to use, attackers will keep targeting the weakest path.

In Japan, the pressure appears more visible because frequent credential entry still remains common, and phishing is viewed as the top threat by most respondents. That combination points to a familiar governance problem: user experience, trust, and recovery processes still shape identity risk as much as the authentication method itself.

Key questions

Q: What breaks when passwordless is deployed but fallback authentication still exists?

A: Passwordless loses most of its value when passwords, recovery codes, or manual resets remain available behind the scenes. Attackers target the fallback path because it is usually less monitored and easier to socially engineer. A programme is only as strong as its weakest recovery option, not its primary login method.

Q: Why do help desk processes become a security risk in identity programmes?

A: Help desks can become an attack path when staff can reset access or change factors without strong verification. If an attacker can impersonate a user and convince support to restore access, the organisation has effectively turned operational trust into an authentication bypass.

Q: How do security teams know if passwordless is actually reducing risk?

A: They should look beyond adoption rates and measure fallback dependence, recovery frequency, and the number of accounts that still require password-based exceptions. If users or support teams keep reverting to old methods, the control has not truly replaced the legacy risk.

Q: Who is accountable when identity recovery is abused for account takeover?

A: Accountability typically spans IAM owners, help desk operations, and security governance because the failure sits in the recovery process, not only in the login method. If reset workflows are weak, the organisation owns that control gap and must govern it as part of identity assurance.

Technical breakdown

Why identity-related breaches keep scaling

Identity-related breaches scale when attackers can move from initial account compromise into trusted access paths faster than defenders can verify, revoke, or contain them. The report’s numbers suggest this is no longer a niche issue. Identity touches authentication, help desk workflows, recovery, delegation, and privileged access, so a single weak link can turn into enterprise-wide exposure. For practitioners, the mechanism matters more than the label: identity is now a control plane, not just a login screen.

Practical implication: Map breach paths across authentication, recovery, and privileged access instead of treating identity as a front-door control.

Why passwordless progress stalls in real environments

Passwordless does not fail because the concept is weak. It stalls when recovery, device trust, legacy applications, and user support processes still depend on passwords behind the scenes. If users cannot authenticate consistently across all applications and break-glass paths, passwordless becomes partial rather than primary. That leaves organisations with a hybrid state where the weakest fallback often defines the true security posture.

Practical implication: Audit fallback authentication, recovery, and help desk flows before expanding passwordless to more users.

Why help desk hijacking is an identity governance issue

Help desk hijacking sits at the intersection of social engineering and identity governance because the attacker is not breaking cryptography. They are abusing identity support processes to reset access, change factors, or obtain recovery approval. In mature programmes, the help desk is part of the identity perimeter, with scripted verification, risk signals, and escalation controls. When those controls are inconsistent, the attacker uses process trust as an access path.

Practical implication: Treat identity support workflows as privileged entry points and apply verification and approval controls to them.

Threat narrative

Attacker objective: The attacker aims to turn identity trust into durable access that can bypass normal authentication controls and create downstream breach impact.

1. Entry begins with phishing, help desk social engineering, or another identity-recovery abuse path that gives the attacker a foothold into trusted authentication workflows.
2. Escalation follows when the attacker uses recovery, reset, or support channels to obtain higher-trust access than the original login would allow.
3. Impact occurs when the attacker converts that trusted identity into account takeover, data access, or breach-driven cost amplification across the environment.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

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

NHI Mgmt Group analysis

Identity breach growth is now a governance failure, not just an authentication failure. The report shows 69% of organisations experienced an identity-related breach in three years, which means the attack surface is now distributed across login, support, recovery, and privileged access. Traditional IAM controls still focus too narrowly on user sign-in events. Practitioners should read this as a programme-design problem, not a point-in-time authentication problem.

Help desk hijacking exposes the identity support layer as part of the perimeter. When attackers can impersonate users and win a reset or recovery path, they are not defeating MFA, they are bypassing the governance that surrounds it. That makes support workflows a control plane with verification, approval, and exception management requirements. Security teams need to treat help desk identity assurance as operationally material.

Passwordless progress is being constrained by fallback dependence and incomplete lifecycle design. The report’s adoption gap shows that organisations often preserve password-based escape hatches even while claiming to move beyond them. Those fallback paths become the real standard in practice. The implication is that identity modernisation cannot be measured by the primary method alone; it must be measured by the weakest recovery path.

Standing trust in recovery processes is the real hidden exposure. Many IAM programmes assume that if the primary authenticator is strong, the surrounding recovery and exception processes can remain looser. That assumption fails when attackers target the recovery layer directly and use it to inherit trust. The implication is that identity risk must be governed as an end-to-end trust chain, not as a single authentication control.

Identity risk now spans human, privileged, and machine-access programmes. Even though the report is framed around human identity, the governance lesson is broader. The same design flaw appears wherever an identity can be recovered, reassigned, or over-trusted without strong lifecycle boundaries. Practitioners should align human IAM, NHI governance, and privileged access controls to the same trust discipline.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how weak lifecycle control remains across machine access.
• That same lifecycle gap is why practitioners should also review 52 NHI Breaches Analysis for recurring patterns in over-privilege and missed revocation.

What this signals

Identity support workflows now deserve the same control scrutiny as privileged access. If your team can reset authentication or re-issue trust without strong verification, you have built an alternate entry path for attackers. The programme signal is clear: recovery design is part of identity architecture, not an afterthought.

Passwordless programmes will only mature when fallback paths disappear in practice. Organisations can report impressive adoption while leaving password-based recovery, manual overrides, and help desk exceptions in place. That is why the control objective should be reduction of recoverable trust, not just adoption of a new sign-in method.

With 97% of NHIs carrying excessive privileges, the identity governance problem is already broader than human login. The same governance logic that exposes users through weak recovery flows also exposes service accounts, tokens, and APIs when lifecycle controls lag behind access growth.

For practitioners

• Map the full identity recovery chain Document every path that can restore or override access, including help desk resets, backup factors, delegated approvals, and exception handling. Identify where a weaker path can bypass your strongest control.
• Harden help desk verification rules Require risk-based verification, step-up checks, and supervisor approval for high-impact account changes, especially when the request affects factor resets or privileged roles.
• Measure passwordless by fallback exposure Track how often users still rely on passwords, temporary bypasses, or legacy authentication paths in production and recovery workflows. Primary-method adoption is not enough if fallback use remains high.
• Align privileged access and identity recovery controls Apply stricter approval and logging requirements to privileged resets, service account changes, and emergency access paths so recovery cannot become an escalation route.

Key takeaways

• Identity breaches are increasingly driven by the surrounding trust chain, not just by weak login controls.
• The report’s data shows a material jump in both breach frequency and financial impact, which raises the governance stakes for IAM leaders.
• Teams should measure the security of fallback, recovery, and support workflows if they want passwordless and identity modernisation to reduce real risk.

Key terms

• Passwordless Authentication: A sign-in approach that removes passwords from the primary login flow by using stronger authenticators such as biometrics, device-bound credentials, or hardware keys. In practice, the security value depends on whether fallback and recovery paths are equally controlled, because those paths often become the real target.
• Identity Recovery: The set of processes used to restore access when a user loses an authenticator or cannot complete sign-in. It is often the weakest part of an identity programme because it relies on trust, support procedures, and exception handling, all of which attackers can target directly.
• Help Desk Hijacking: A social engineering tactic in which an attacker persuades support staff to reset credentials, change factors, or restore access. It works by abusing organisational trust in the support workflow rather than breaking the underlying authentication technology.
• Fallback Authentication: Any alternate sign-in method that users or administrators can invoke when the preferred authentication method is unavailable. It is a critical risk point because organisations often secure the primary method but leave fallback paths less visible, less monitored, and easier to abuse.

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 governance in your organisation, it is worth exploring.

This post draws on content published by RSA Security: Soaring Identity Costs and Stalling Passwordless Progress in Japan: RSA ID IQ Report Unveils Top Identity Threats. Read the original.