And why no amount of MFA will fix it...

For decades, enterprise identity has been built around a single assumption - if someone can successfully authenticate, they must be the right person.

That assumption was always weak and today, it is demonstrably false.

Despite billions of dollars invested in identity platforms, MFA technologies, and Zero Trust architectures, organisations are still routinely breached through identity. Social engineering remains effective, Help Desks are compromised. Privileged access is abused. Former employees retain access. And attackers increasingly operate as trusted insiders, not external threats.

This is not a failure of execution - It is a failure of the mental model underpinning identity.

The problem is not that authentication is weak - The problem is that authentication is the wrong control for many of the risks we are trying to manage.

Authentication proves access - It does not prove identity.

The Historical Model: accounts, credentials, and trust by proxy

Traditional identity systems evolved to answer one question:

“Should this account be allowed to access this system?”

That made sense when:

• Users were internal
• Systems were centralised
• Networks were trusted
• Threat actors were unsophisticated

Identity became synonymous with:

• A username
• A password
• Later, a second factor

Over time, we layered:

• Federation
• SSO
• MFA
• Conditional access
• Identity governance

Each layer improved control over access, none of them improved assurance of who the human actually was.

Even today, when a user logs in successfully, the system only knows:

• Someone had the right credentials
• Someone satisfied the authentication policy
• Someone passed the risk engine at that moment

It does not know:

• Whether that person is who they claim to be
• Whether they are acting on their own behalf
• Whether they are being coerced or socially engineered
• Whether they are still a legitimate member of the organisation

Identity proofing is the act of establishing who someone is, and this happens once, early in the lifecycle, and is rarely revisited. Everything else is inference.

Why MFA didn’t solve the problem (and never could)

MFA is often presented as the definitive solution to identity compromise, it isn’t.

MFA answers a very narrow question:

“Does the person attempting access possess multiple authentication factors?”

It does not answer:

• Who that person is
• Whether the identity has been compromised socially
• Whether the interaction itself is legitimate

Attackers adapted quickly:

• MFA fatigue attacks
• Real-time phishing proxies
• Help desk social engineering
• Session hijacking
• SIM swap attacks

More importantly, MFA still operates inside the same flawed model:

• Authenticate the session
• Assume the identity is valid

Even phishing-resistant MFA only raises the bar for credential theft.

It does nothing to address identity misuse. This is why breaches continue despite MFA.

The help desk problem: where identity really breaks

If you want to understand why login-centric identity is broken, look at the help desk. Help desks don’t authenticate sessions, they authenticate people.

They do this using:

• Knowledge-based questions
• HR records
• Manager approval
• Gut feel

In other words, they operate outside IAM entirely. Attackers know this, that’s why help desks are now a primary entry point.

When a help desk resets credentials, they are effectively:

• Re-issuing identity
• Without cryptographic assurance
• Based on human judgement

No IAM system can fix this, because IAM systems were never designed to operate in human interaction workflows. This is the gap Verified Credentials fill.

The Core Flaw: Identity proofing is not continuous

Most organisations treat identity proofing as a one-time event:

• At onboarding
• During KYC
• During account creation

After that, identity is assumed.

But identity is not static:

• People change roles
• Devices change
• Behaviour changes
• Threat levels change
• Relationships change

Yet we continue to rely on:

• Credentials issued months or years ago
• Assumptions of legitimacy
• Indirect signals

This is why identity failures are so hard to detect, the system believes everything is normal.

What identity proofing should look like instead, in a modern environment, identity assurance must be:

• Portable — usable across systems
• Cryptographic — not knowledge-based
• Contextual — applied when risk is high
• Repeatable — not a one-off event
• Revocable — instantly and globally

This is exactly what Verifiable Credentials enable.

A Verifiable Credential allows an organisation to:

• Issue cryptographic proof of identity or role
• Have the holder present that proof when required
• Verify it without calling back to a central system
• Revoke it instantly if trust changes

Importantly, credentials are used when identity matters, not just at login:

• Help desk interactions
• Privileged operations
• High-risk transactions
• Breach recovery
• Cross-organisation access

This is not “stronger authentication”, it is a different control entirely.

Why this is a category shift, not an IAM feature

Many vendors attempt to position Verified Credentials as:

• Another authentication factor
• A wallet strategy
• A digital ID replacement

All of these miss the point.

Verified Credentials are not about logging in. They are about proving who you are when trust actually matters.

This is why they sit alongside IAM, not inside it. This is why orchestration matters more than issuance. And this is why organisations adopting VC’s see value outside traditional access flows first.

If identity proofing only happens at login, your organisation does not have identity assurance, it has access control.

As attackers continue to exploit human workflows, social engineering, and trust assumptions, this gap will only widen.

Verifiable Credentials do not replace IAM, they fix what IAM was never designed to do.