Most organisations believe they understand identity breaches.

They track them, respond to them, and report on them. They have incident response plans, tabletop exercises, and post-incident reviews.

And yet, the same organisations are repeatedly compromised through identity, often involving the same users, the same workflows, and sometimes the same attackers.

This is not because security teams are incompetent or under-resourced.

It is because most organisations are solving the wrong problem.

They are treating breached credentials as if they are the same thing as breached identity.

They are not!

Credentials are artefacts. Identity is trust.

A credential is an artefact:

• A password
• A private key
• A token
• A session cookie
• A device registration

Credentials are evidence that something knows a secret or holds a token.

Identity, by contrast, is a trust relationship between:

• An organisation
• A human (or agent)
• A set of permissions and responsibilities

When credentials are compromised, what is really at risk is not the secret, it is the organisation’s confidence that the identity behind it is legitimate.

Most incident response processes stop at the artefact.

That is the mistake!

The standard breach response and its blind spots

A typical identity breach response looks like this:

1. Detect suspicious activity
2. Disable the account
3. Reset passwords
4. Re-enrol MFA
5. Review logs
6. Restore access

This approach assumes:

• The compromise was technical
• The attacker no longer has access
• Trust can be restored by rotating secrets

But modern breaches are rarely that simple.

Attackers increasingly gain access through:

• Social engineering
• Help desk impersonation
• Coercion
• Shared credentials
• Process abuse

In these cases, resetting credentials does not restore trust, it merely re-enables access without re-establishing identity assurance.

Why attackers come back after “successful” remediation

Security teams are often surprised when the same account is compromised again weeks or months later.

From the attacker’s perspective, this makes perfect sense.

If they have:

• Learned internal processes
• Identified weak identity checks
• Established credibility with staff
• Understood escalation paths

Then resetting credentials is a temporary inconvenience, not a barrier.

The organisation has treated the incident as a credential problem, while the attacker is exploiting an identity problem.

The identity confidence gap

After a breach, there is an uncomfortable question most organisations never formally ask:

“Do we still trust that this person is who they claim to be?”

Instead, trust is implicitly restored through technical resets:

• Password changed → trusted again
• MFA re-registered → trusted again
• Account unlocked → trusted again

At no point is the human identity re-proven in a cryptographically verifiable way.

This is not negligence, it’s a tooling limitation.

Traditional IAM systems were never designed to re-prove identity after compromise. They manage access, not trust restoration.

Why “strong authentication” doesn’t solve breached identity

Even phishing-resistant MFA assumes:

• The person enrolling the factor is legitimate
• The enrolment process itself was not compromised
• The identity proofing that happened months or years ago is still valid

In a post-breach scenario, these assumptions no longer hold.

If an attacker successfully impersonated a user once, the organisation must assume:

• Identity assurance is degraded
• Trust must be re-established, not assumed

Strong authentication verifies possession of a factor.

It does not verify who is in possession of it.

Breached identity requires re-proofing, not resets

A breached identity requires a fundamentally different response:

• Re-verification of the human
• Independent of compromised credentials
• Using stronger evidence
• With auditable proof
• And explicit re-issuance of trust

This is operationally difficult — and often avoided — because most organisations lack a mechanism to do it at scale.

This is precisely where Verifiable Credentials change the equation.

How Verifiable Credentials enable true post-breach recovery

With Verifiable Credentials, an organisation can:

• Instantly revoke all previously issued credentials associated with an identity
• Require the individual to re-prove their identity using defined evidence
• Issue a new credential cryptographically bound to that individual
• Restore access selectively, based on verified identity rather than historical trust

This process:

• Separates identity re-establishment from access re-enablement
• Reduces blast radius
• Prevents silent re-compromise
• Provides a defensible audit trail

Most importantly, it restores confidence, not just connectivity.

Executive and board implications

Boards increasingly ask:

• “How do we know this won’t happen again?”
• “What changed as a result of this breach?”

If the answer is:

• “We reset passwords”
• “We tightened policies”
• “We added another factor”

Then nothing fundamental has changed.

Being able to say:

“We can re-establish identity assurance independently of credentials” is a materially different risk posture.

Credential compromise is a technical incident.

Identity compromise is a trust failure.

If your breach response treats them as the same thing, you are fixing symptoms, not causes.

Verifiable Credentials give organisations a way to explicitly restore trust, not just rotate secrets.