Passwords remain the dominant identity attack surface in enterprise IAM

At a glance

What this is: This is an opinion-led IAM article arguing that passwords are still the main breach vector and that browser-based identity should move away from user-managed secrets.

Why it matters: It matters because password dependence affects human IAM, service-account hygiene, and broader identity governance assumptions about what users can safely manage.

By the numbers:

• At Unixi, our weekly enterprise discoveries reveal weak or default passwords in 100% of organizations we assess.
• Traditional SSO helps, but as many as 50% of enterprise apps still don’t support SAML integration.
• Passkeys are supported by only 100–200 apps, while FIDO keys work with about 800.

👉 Read Unixi’s article on eliminating password risk in browser-based IAM

Context

Passwords remain the default control for browser access because they are deeply embedded in human IAM workflows, but they also preserve the oldest and most exploitable identity failure mode. The article’s core claim is that users cannot be expected to consistently manage strong secrets under pressure, which makes password dependence a governance problem as much as a technical one.

The practical identity issue is not whether passwords can be made stronger in theory. It is whether organisations can rely on human behaviour, app coverage, and recovery processes to hold up under phishing, reuse, credential stuffing, and secret storage mistakes. On that measure, the article argues the model is broken across both employee access and service-account handling.

Key questions

Q: How should IAM teams reduce password-related productivity loss?

A: They should start by measuring where password failures interrupt work most often, then redesign the highest-friction journeys first. That means stronger recovery flows, clearer enrolment, and expanding phishing-resistant methods where business impact is highest. If the programme cannot show reduced lockouts and faster restoration, the control change has not yet improved identity operations.

Q: Why do weak passwords keep causing breaches even when users are trained?

A: Training does not change the underlying constraint that people are asked to invent and remember complex secrets under cognitive load. If the system accepts weak credentials, reused patterns, or bypassed reset paths, the organisation is still vulnerable. The real fix is architectural enforcement at creation, rotation, and offboarding.

Q: What breaks when password policies are not enforced across legacy systems?

A: The control breaks where the organisation cannot apply rotation, logging, or recovery consistently. Legacy systems often create invisible exceptions, which means the most sensitive accounts may sit outside normal oversight. That makes identity governance harder to evidence and can leave underwriting reviews exposed to undocumented risk.

Q: Who is accountable for the exceptions in a passwordless rollout?

A: IAM, endpoint, and platform teams share accountability because the exceptions usually arise at the boundary between device support, application integration, and remote access design. Governance should require explicit ownership for every unsupported use case, so fallback methods do not become unmanaged permanent controls.

Technical breakdown

Why password-based identity keeps failing in practice

Password security fails because it depends on human memory, consistent reuse discipline, and correct handling of secrets across too many systems. Once credentials are reused, written down, saved in browser vaults, or exposed through phishing, the identity control becomes a reusable bearer secret rather than a durable proof of intent. In IAM terms, the authentication factor is only as strong as the weakest storage and recovery path around it.

Practical implication: reduce the number of places where users or admins can create, view, export, or reuse passwords.

Why SSO, passkeys, and FIDO do not close every gap

Single sign-on reduces password exposure, but only where applications support federation. Passkeys and FIDO improve phishing resistance, yet adoption is still constrained by application compatibility, device support, and migration complexity. The result is a split control plane: some apps are protected by modern authentication, while legacy and long-tail browser apps still depend on passwords or shared credentials.

Practical implication: treat coverage gaps as identity risk, not rollout noise, and map which applications still rely on passwords.

How browser-based password elimination changes identity architecture

Removing passwords shifts authentication from user-managed secrets to cryptographic or derived authentication flows that users do not know or reuse. That changes the attack surface from credential theft and phishing to trust in the authentication boundary itself, including recovery, session binding, and application coverage. The architectural question becomes whether the new method truly removes secret possession from the user path or simply moves it elsewhere.

Practical implication: test whether the proposed passwordless model actually eliminates user-held secrets across the full application estate.

Threat narrative

Attacker objective: The attacker wants durable account access that can be reused to reach applications, stored credentials, and sensitive records with minimal resistance.

1. Entry occurs through weak, reused, or default passwords, or through phishing that captures valid user credentials.
2. Escalation follows when attackers reuse those credentials across applications, access password managers, or steal stored service-account secrets.
3. Impact is account takeover, data exposure, and broader breach propagation because one compromised secret can unlock multiple systems.

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

Password reliance is a human governance failure, not a user-training problem. The article’s strongest point is that organisations keep outsourcing identity discipline to end users who are under time pressure and rewarded for speed. That model predictably produces reuse, note-taking, browser storage, and phishing success. The implication is that IAM programmes should stop treating password hygiene as a behaviour issue and treat it as an architecture issue.

Enterprise password scope is wider than human login risk. The same credential habits that weaken employee access also normalise poor handling of service-account and browser-stored secrets. That makes password dependence a cross-domain identity problem spanning human IAM, NHI governance, and recovery workflows. Practitioners should read password removal as part of broader identity lifecycle redesign, not as a standalone authentication upgrade.

Browser app coverage remains the real constraint on passwordless maturity. Federation and passkeys reduce risk, but the long tail of unsupported applications keeps passwords alive in the estate. The named concept here is password exception debt: each unsupported app becomes a permanent governance exception that attackers can still target. Security teams need to measure exception debt, not just celebrate modern authentication adoption.

Identity assurance should be measured by secret removal, not policy intent. A programme can have strong password policy language and still fail if users can export, reuse, or store credentials in easy-to-abuse places. That is why the real question is whether the organisation has removed user-held secrets from the access path. Practitioners should judge identity controls by how much secret exposure they eliminate in practice.

Eliminating passwords changes the threat model, but not the need for governance. If authentication moves to cryptographic derivation or passwordless flows, the security focus shifts to recovery, session control, application compatibility, and exception handling. The implication for identity leaders is clear: password removal reduces a major attack surface, but only if it is governed as a full programme rather than a point solution.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how weak identity inventory still is in practice.
• The broader control gap is documented in 52 NHI Breaches Analysis, where recurring credential exposure patterns show why identity governance must go beyond passwords.

What this signals

Password exception debt: the long tail of unsupported applications will keep passwords alive unless teams actively measure and retire the exceptions. In practice, that means building a living register of legacy logins, fallback flows, and shared credentials before any passwordless programme can be trusted.

The same governance discipline applies across human access and NHI access, because both collapse when secrets are easy to copy and hard to revoke. For practitioners, the next maturity step is not another password rule but a control model that removes user-held secrets from the access path wherever the estate allows it.

For practitioners

• Map password exception debt across the application estate Inventory every browser-based application that still relies on passwords, including legacy apps, external SaaS, and admin portals. Tag each exception by business criticality, user population, and whether federation or passwordless support is blocked by the application or by process.
• Prioritise secret removal over password complexity rules Shift from forcing longer passwords to eliminating user-held credentials where practical. Focus first on high-risk access paths such as shared admin logins, stored service-account credentials, and applications where password reuse is most likely.
• Review recovery and fallback paths as part of authentication design Test what happens when users lose devices, miss enrollment, or need break-glass access. If the fallback path reintroduces passwords, helpdesk resets, or easy secret export, the passwordless control still leaves a breach-ready back door.
• Track where federation coverage still fails Build a control register for the apps that do not support SAML, modern passkeys, or equivalent passwordless options. Use that register to guide retirement, remediation, or compensating controls for the weakest identity paths.

Key takeaways

• Passwords remain a structural identity weakness because they depend on human behaviour, not just policy.
• The article’s evidence points to widespread exception handling, weak secret hygiene, and incomplete app coverage as the real blockers to safer authentication.
• Practitioners should measure progress by how many user-held secrets they remove, not by how many password rules they add.

Key terms

• Password Exception Debt: The accumulation of applications, fallback flows, and legacy systems that still require passwords even after an organisation adopts modern authentication. It is an identity governance liability because every exception preserves a reusable secret path that attackers can still target.
• 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.
• Secret Exposure Surface: Secret exposure surface is the set of places where credentials can be read, copied, or misused by systems and integrations. It includes environment variables, configuration stores, runtime memory, and connected tools. Reducing the surface means limiting both storage and reachability, not just encrypting data at rest.

What's in the full article

Unixi's full article covers the operational detail this post intentionally leaves for the source:

• A vendor-specific breakdown of how Universal SSO and KDA handle browser-based authentication across legacy and SaaS applications.
• Implementation claims around password disappearance, phishing resistance, and application coverage gaps that are not unpacked here.
• The article’s comparison of passwordless approaches with traditional SSO, passkeys, and FIDO from the vendor’s perspective.
• Commercial and rollout context that practitioners would need before deciding whether the approach fits their environment.

👉 Unixi’s full post covers the passwordless model, application coverage limits, and the vendor’s comparison with SSO, passkeys, and FIDO.

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.