Black Hat USA 2026 — The Architecture of Trust Is Changing, Part 8

Why phishing-resistant authentication does not end identity compromise

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

For years, cybersecurity has had a remarkably clear identity objective:

Kill the password.

Passwords are reusable.

They can be guessed phished, stuffed., sprayed, shared, replayed, stolen from databases, captured by malware and reused across services.

The industry therefore spent years building a better authentication architecture.

• MFA.
• FIDO2.
• WebAuthn.
• Hardware security keys.
• Windows Hello.
• Passkeys.
• Phishing-resistant authentication.

That transition is necessary.

Enterprises should accelerate it.

But Black Hat USA 2026 exposed an uncomfortable reality:

Removing the password does not remove the identity attack surface.

It moves it.

Attackers do not need to remain loyal to password theft.

If credentials become harder to steal, they will attack:

• the implementation,
• the endpoint,
• the session,
• the token,
• the enrollment process,
• the recovery process,
• the identity provider,
• the application,
• the authorization path,
• the machine identity,
• or the trust relationship surrounding authentication.

That leads to the central argument of Part 8:

Phishing-resistant authentication is not the end of identity security. It is the beginning of identity architecture after passwords.

Authentication Is a Moment

Consider what happens when a user signs into an enterprise application.

The user proves something.

Perhaps:

• knowledge,
• possession,
• biometric presence,
• device possession,
• or cryptographic control of a private key.

The identity provider evaluates that proof.

Authentication succeeds.

Then something important happens.

The authentication ceremony ends.

But the user’s authority continues.

The user receives:

• a session,
• a token,
• a cookie,
• an access token,
• a refresh token,
• a Kerberos ticket,
• a cloud identity,
• or another representation of authenticated authority.

From that point onward, most enterprise systems do not repeatedly ask:

Can this human still prove who they are?

They ask:

Does this session or token represent an authenticated identity?

That distinction creates the next attack surface.

Strong Authentication Can Produce a Weak Session

Imagine a user authenticating with an excellent hardware-backed credential.

The cryptography is strong.

The credential is phishing-resistant.

The authentication ceremony is legitimate.

Everything works exactly as intended.

The application then creates a bearer session.

If an attacker steals that session, the attacker may no longer need the credential.

They need the result of the authentication.

This produces an important distinction:

Authentication Assurance ≠ Session Assurance

The enterprise may have invested heavily in securing the first five seconds of access.

But the session may remain active for hours.

Or days.

The attacker will naturally move toward the weaker part of that chain.

Black Hat’s Passkey Signal

One of the most interesting identity briefings at Black Hat USA 2026 was:

Pass-the-Passkey Family of Attacks.

The important lesson should not be simplified into:

Passkeys are broken.

That would be wrong.

The research is much more interesting precisely because the underlying WebAuthn cryptography did not need to be broken.

The attack family examined weaknesses in real-world implementations and the systems surrounding passkey authentication.

That distinction matters enormously.

Security standards can be strong.

Cryptography can be strong.

And the deployed identity system can still fail.

This is the recurring architectural lesson of Black Hat 2026:

Attackers increasingly attack the composition, not necessarily the primitive.

The Cryptography Can Hold While the Identity Fails

This is one of the most important ideas for CISOs to understand.

Security teams naturally ask:

• Is FIDO2 secure?
• Is WebAuthn secure?
• Is the cryptography secure?

Those are important questions.

But an attacker may never need to answer them.

The attacker can ask something else:

Where does the trusted assertion go next?

Perhaps it appears in memory.

Perhaps some representation is logged.

Perhaps a browser handles it incorrectly.

Perhaps a cloud implementation validates it incorrectly.

Perhaps an authenticated session can invoke the credential.

Perhaps enrollment creates another path.

Perhaps recovery bypasses the stronger authentication method.

The cryptography can remain perfectly intact.

The attacker simply goes around it.

Pass-the-Passkey Changes the Question

The name itself is useful.

For decades, defenders dealt with:

Pass-the-Hash.

The attacker did not necessarily need to recover the original password.

The attacker needed something the system accepted as equivalent authority.

That same conceptual pattern continues.

Attackers increasingly ask:

What artifact, state or execution context does the system trust after authentication?

That might be:

• a session cookie,
• a refresh token,
• a Kerberos ticket,
• an OAuth token,
• a signed assertion,
• a browser session,
• a device registration,
• a workload credential,
• or an existing authenticated context.

This leads to a broader principle:

Attackers do not need your credential if they can steal, replay, invoke or inherit the authority it created.

Identity Security Must Move Beyond Credential Security

This distinction is critical.

Credential security asks:

Can the attacker steal the secret used to authenticate?

Identity security asks:

Can the attacker obtain or exercise the authority associated with the identity?

Those are not the same problem.

An attacker may compromise identity authority through:

• credential theft,
• session hijacking,
• token replay,
• endpoint compromise,
• OAuth abuse,
• application consent,
• device enrollment,
• recovery mechanisms,
• delegation,
• service principals,
• managed identities,
• machine credentials,
• or authorization-chain manipulation.

The password is only one path.

Removing it closes an important path.

But the graph remains.

The Endpoint Becomes Part of Authentication

Phishing-resistant authentication changes the role of the endpoint.

When credentials are hardware-backed or device-bound, the attacker may increasingly attack the environment allowed to invoke them.

This means endpoint security and identity security converge.

Consider a compromised workstation.

The attacker may not be able to extract the hardware-protected private key.

Excellent.

But perhaps the attacker does not need to.

If malicious code executes inside an already authenticated environment, it may be able to:

• use existing sessions,
• invoke applications,
• trigger authentication flows,
• access tokens,
• interact with browsers,
• use delegated permissions,
• or perform actions through the user’s authenticated context.

The question therefore changes from:

Can the attacker steal the key?

to:

Can the attacker cause the trusted endpoint to use the key or the authority derived from it?

That is a much larger problem.

Device Trust Becomes Identity Trust

This creates an architectural consequence.

If authentication relies on a trusted device, then device integrity becomes part of identity assurance.

The identity equation increasingly becomes:

**User Identity
Authenticator
Device
Session
Context
= Effective Trust**

Weakness in any one of those components can undermine the result.

That means phishing-resistant authentication should increasingly be combined with:

• device compliance,
• endpoint detection,
• hardware-backed device identity,
• attestation,
• conditional access,
• session protection,
• risk signals,
• and continuous evaluation.

Identity is no longer something proved only at login.

It becomes something maintained throughout execution.

Authentication Is Becoming Continuous

The traditional identity model looks like this:

Authenticate Once
→ Trust Session

The emerging model needs to look more like:

Authenticate
→ Establish Session
→ Observe Context
→ Re-evaluate Risk
→ Maintain or Reduce Authority
→ Revoke When Necessary

That is continuous identity assurance.

Signals may include:

• device health,
• location,
• network context,
• session behavior,
• token use,
• privilege escalation,
• impossible travel,
• endpoint compromise,
• resource sensitivity,
• behavioral anomalies,
• or changes in authentication strength.

The objective is not constant MFA prompts.

That would simply create friction.

The objective is continuous evaluation of whether the assumptions that justified access still hold.

The Session Is the New Password

This is deliberately provocative.

But it captures an important shift.

Passwords were attractive because they were portable proof of authority.

Steal the password.

Reuse it elsewhere.

Modern authentication tries to eliminate that portability.

But bearer sessions and tokens can recreate the same property.

If possession of a token is sufficient to exercise authority, then the token becomes:

portable trust.

That is precisely what attackers want.

The industry therefore needs to move beyond:

phishing-resistant authentication

toward:

replay-resistant authority.

This means binding authority more strongly to:

• device,
• workload,
• session,
• context,
• and intended use.

Bearer Tokens Are an Architectural Weakness

A bearer token effectively says:

Whoever presents me may exercise this authority.

That is operationally convenient.

It is also structurally dangerous.

If attackers can steal the token, they inherit its authority.

No password required.

No MFA prompt required.

No cryptographic attack against the authenticator required.

This is why token protection, proof-of-possession mechanisms, device binding and short-lived credentials become increasingly important in a passwordless enterprise.

The objective should be:

Stealing the artifact should not be enough.

Identity Must Become Context-Bound

The stronger architecture is not simply:

Identity X may access Resource Y.

It is closer to:

Identity X
 using Device A
 through Session B
 under Risk State C
 for Purpose D
 may perform Action E
 on Resource Y
 for Time Z.

That sounds more complex.

Because it is.

But that complexity already exists implicitly.

Attackers exploit the gaps between those conditions.

Modern identity architecture needs to make them explicit.

This is Zero Trust applied properly to identity.

Not:

Never trust anyone.

But:

Never allow yesterday’s authentication decision to become unlimited trust for tomorrow’s action.

Recovery Is Part of the Authentication Boundary

There is another problem.

Organizations can deploy extremely strong authentication and then undermine it through weak recovery.

Suppose a privileged administrator uses:

hardware-backed phishing-resistant authentication.

Excellent.

Then the administrator loses the device.

What happens?

Can the account be recovered through:

help desk verification,

email,

SMS,

manager approval,

knowledge-based questions,

temporary access credentials,

or manual administrator intervention?

If the recovery path is weaker than the primary authentication path, attackers will attack recovery.

This produces a simple principle:

The effective strength of authentication is bounded by the weakest path capable of restoring access.

Passwordless architecture therefore requires recovery architecture.

Enrollment Is Also an Attack Surface

The same applies before authentication begins.

Who is allowed to register a passkey?

From which device?

Under what existing authentication?

Can another authenticator be added?

Can a compromised session enroll a new credential?

Can a help desk bootstrap one?

Can malware trigger enrollment?

How is device provenance established?

The security team cannot assess authentication strength by examining only the normal login flow.

The complete lifecycle is:

Identity Proofing
→ Enrollment
→ Authentication
→ Session
→ Authorization
→ Recovery
→ Revocation

Every stage matters.

Authorization Is the Real Destination

Attackers rarely compromise identities because they enjoy authentication.

They compromise identities because identities possess authority.

The actual objective might be:

• read sensitive information,
• modify infrastructure,
• approve payments,
• change source code,
• create persistence,
• disable security controls,
• access cloud resources,
• or move laterally.

That means the ultimate security question is not:

How did the identity authenticate?

It is:

What can this identity cause the enterprise to do?

That brings Part 8 directly back to Part 1.

Identity is ultimately about authority.

Authentication is only the ceremony through which some of that authority becomes accessible.

Black Hat’s Managed Identity Signal

Black Hat USA 2026 also included another briefing with an unusually important title:

Trust No Deputy: Breaking Azure and GCP Through Managed Identity Chains.

This points toward another identity transition.

Not every important enterprise identity is human.

Modern cloud environments contain:

• service principals,
• managed identities,
• workload identities,
• service accounts,
• API identities,
• automation identities,
• CI/CD identities,
• containers,
• functions,

and increasingly:

• AI agents.
• Many never type passwords.
• Many never perform MFA.
• Many already live entirely in the post-password world.
• And attackers are already learning to traverse their trust relationships.

Machine Identities Are Already Passwordless

This creates an interesting paradox.

Enterprises often discuss passwordless authentication as a future transformation for humans.

Machine identities arrived there years ago.

They authenticate using:

• certificates,
• keys,
• tokens,
• federation,
• workload identity,
• cloud metadata,
• signed assertions,
• and platform trust.

Yet machine identity compromise remains one of the most consequential attack paths in modern cloud infrastructure.

Why?

Because removing passwords did not remove:

• excessive privilege,
• credential exposure,
• weak federation,
• poor lifecycle management,
• trust chaining,
• token theft,
• misconfiguration,
• or delegation abuse.

Machine identity already proves the central thesis of this article:

Passwordless does not mean identity-secure.

Ghost Credentials

Black Hat’s 2026 program also included:

Ghost Credentials: Hunting and Exploiting NonHuman Identities Across Cloud Environments.

The phrase captures another major enterprise problem.

Non-human identities accumulate.

Some remain after:

• projects end,
• applications change,
• employees leave,
• cloud resources disappear,
• automation is replaced,
• or integrations are forgotten.

Yet their credentials or trust relationships may remain.

These identities can become invisible authority.

An attacker does not need to compromise a heavily monitored human administrator if an abandoned machine identity already has access.

This is why identity inventory must expand beyond people.

Identity Inventory Is Becoming an Authority Graph

Traditional IAM inventory often looks like:

User → Groups → Roles

Modern enterprise identity looks more like:

Human
→ Device
→ Session
→ Application
→ Token
→ Service Principal
→ Managed Identity
→ API
→ Cloud Resource

And increasingly:

Human
→ Agent
→ MCP Server
→ Tool
→ Workload Identity
→ Enterprise System

The important question becomes:

Where can authority flow?

That is not simply an identity inventory.

It is an authority graph.

And attackers increasingly navigate the graph.

Identity Attack Paths

This changes identity risk management.

Suppose a service principal has limited permissions.

That appears safe.

But it can invoke a workload.

The workload uses a managed identity.

The managed identity can access a secret store.

The secret store contains another credential.

That credential controls a production environment.

No single permission looks catastrophic.

The chain is.

This is the same compositional-security problem that runs through the entire Black Hat 2026 series.

Security teams therefore need to ask:

What authority can be reached through this identity?

Not merely:

What permissions does this identity have directly?

Privilege Is Transitive

Traditional IAM often evaluates privilege locally.

Identity A has Role B.

Role B grants Permission C.

But modern systems contain delegation.

An identity may be able to:

assume another role,

invoke another service,

trigger another workload,

request another token,

cause another agent to act,

or access another credential.

That means effective privilege can be transitive.

A useful model is:

**Effective Privilege
= Direct Authority
Delegated Authority
Reachable Authority**

This becomes especially important for AI agents.

An agent’s own identity may appear minimally privileged.

But if it can invoke tools that operate through more powerful identities, its effective authority is much larger.

Agents Make Identity More Complicated

Parts 1 through 5 already established why AI agents change enterprise security.

Part 8 adds another implication.

An agent may operate:

• for a human,
• through a machine identity,
• using a delegated token,
• against a service,
• through an MCP server,
• while consuming untrusted context.

Whose identity is performing the action?

The human?

The agent?

The MCP server?

The service principal?

The application?

The workload?

All of them may be involved.

That creates a fundamental audit problem.

Enterprises need to preserve the complete chain:

Human Intent
→ Agent Identity
→ Delegation
→ Tool Identity
→ Resource
→ Action

Otherwise logs may show only the final service identity.

And the actual authority path disappears.

“On Behalf Of” Must Become Visible

This suggests a critical design requirement for agentic identity.

Delegation must remain attributable.

If an agent acts on behalf of a human, the system should preserve:

• who initiated the objective,
• which agent interpreted it,
• which identity the agent used,
• which tool executed the action,
• which policy authorized it,
• and which resource changed.

The enterprise should not collapse that chain into:

Service Account X changed Resource Y.

That may be technically correct.

But from an accountability perspective, it is almost useless.

Identity after passwords therefore requires stronger delegation provenance.

Authentication Strength Should Follow Consequence

Not every action requires the same assurance.

Reading a public document is different from:

exporting sensitive data,

changing payment instructions,

granting privileged access,

deploying code,

or disabling a security control.

The architecture should therefore connect authentication and authorization strength to consequence.

High-impact actions may require:

fresh authentication,

step-up authentication,

device attestation,

human confirmation,

dual authorization,

transaction signing,

or independent policy enforcement.

The important point is that strong authentication should not occur only at session creation.

It should reappear where authority becomes consequential.

Transaction Integrity Is the Next Frontier

This leads to another conceptual shift.

Authentication asks:

Who are you?

Authorization asks:

Are you allowed?

But high-risk digital systems increasingly need another question:

Is this specific action genuinely intended and trustworthy?

That is transaction integrity.

For example:

A CFO may legitimately have authority to approve a payment.

A passkey may prove the CFO authenticated.

But if malware manipulates the transaction after authentication, both facts can be true:

the correct person authenticated,

and

the wrong transaction was executed.

Strong identity therefore does not automatically create trustworthy action.

This is closely related to Part 5:

Valid authority does not guarantee valid intent.

Identity Security Is Becoming Execution Security

This is the larger lesson.

Identity was once treated largely as:

• accounts,
• passwords,
• authentication,
• and access rights.

But in an increasingly automated enterprise, identity determines:

• what can execute,
• what can change,
• what can communicate,
• what can retrieve,
• what can delegate,
• and what can authorize.

Identity therefore becomes part of the enterprise execution architecture.

The CISO should no longer ask only:

Who has privileged access?

The stronger question is:

Which identities can cause privileged execution — directly or indirectly?

The Post-Password Identity Model

A mature post-password identity architecture therefore needs several layers.

1. Phishing-Resistant Authentication

Eliminate reusable human authentication secrets wherever possible.

2. Trusted Enrollment

Ensure strong credentials cannot be registered through weak processes.

3. Strong Recovery

Prevent recovery from becoming the weakest authentication path.

4. Device Trust

Bind identity assurance to trustworthy execution environments.

5. Session Protection

Prevent authenticated authority from becoming easily replayable.

6. Continuous Evaluation

Reassess trust as context changes.

7. Transaction-Level Assurance

Increase authentication and authorization strength as consequence increases.

8. Machine Identity Governance

Discover, own, rotate, constrain and revoke non-human identities.

9. Delegation Provenance

Preserve who or what acted on behalf of whom.

10. Authority-Path Analysis

Understand reachable privilege, not merely assigned privilege.

That is identity architecture after passwords.

The CISO Control Model

I would translate this into ten practical controls.

1. Accelerate Phishing-Resistant Authentication

Passkeys and hardware-backed credentials remain a major security improvement.

2. Protect the Entire Authentication Lifecycle

Enrollment, recovery and revocation must match primary authentication assurance.

3. Treat Endpoint Integrity as an Identity Signal

Compromised devices should reduce or terminate authority.

4. Protect Sessions and Tokens

Short-lived, bound and context-aware authority should replace portable bearer trust wherever possible.

5. Continuously Re-Evaluate Access

Authentication should not create unconditional long-lived trust.

6. Step Up at the Consequence Boundary

High-impact actions require stronger assurance.

7. Inventory Human and Non-Human Identities

Service principals, workloads and agents belong in the same governance model.

8. Map Identity Attack Paths

Measure direct, delegated and reachable authority.

9. Preserve Delegation Chains

Every consequential action should remain attributable from human intent to execution identity.

10. Revoke Authority Quickly

Identity architecture must support rapid containment of users, sessions, tokens, workloads and agents.

The objective is not merely passwordless.

It is:

non-replayable, context-bound, observable and revocable authority.

What I Would Ask as a CISO Now

I would ask:

• What percentage of privileged users use phishing-resistant authentication?
• Where do passwords still exist?
• Which recovery paths can bypass stronger authentication?
• Who can enroll new authenticators?
• Can a compromised authenticated session register another credential?
• How long do privileged sessions remain valid?
• Which tokens are still portable bearer credentials?
• Can tokens be bound to devices or workloads?
• Can endpoint compromise trigger session revocation?
• Which high-impact actions require fresh authentication?
• Do we know every non-human identity?
• Who owns each one?
• Which are dormant?
• Which have long-lived credentials?
• Which machine identities can assume other identities?
• Which agents act on behalf of humans?
• Can we reconstruct delegation end to end?
• Which identity has the largest reachable authority, not merely the largest assigned role?

And most importantly:

If an attacker cannot steal the password anymore, where will they go next?

That is the attack surface we should be designing for now.

The CISO Architecture Decision

The industry should continue moving aggressively toward phishing-resistant authentication.

Black Hat USA 2026 does not provide an argument against passkeys.

It provides an argument against stopping there.

Because the architecture surrounding authentication remains attackable.

The complete trust chain is:

Identity
→ Authenticator
→ Device
→ Session
→ Token
→ Authorization
→ Delegation
→ Execution

Protecting only the authenticator leaves the rest of the chain exposed.

And attackers are rational.

When one path becomes expensive, they move to the next cheapest path.

That is what good security controls are supposed to do.

But it also means security architecture must keep moving.

From Authentication Assurance to Authority Assurance

For years, identity programs have asked:

How strongly did this user authenticate?

That remains important.

But the more strategic question is becoming:

How strongly can we trust the authority being exercised right now?

That requires more context.

Who authenticated?

How?

On which device?

Under what risk state?

Which session?

Which token?

Acting directly or through delegation?

Through which agent or workload?

Against which resource?

For which action?

With what consequence?

That is a different security model.

It moves us from:

Authentication Assurance

toward:

Authority Assurance.

And authority assurance persists long after the login screen disappears.

The CISO Takeaway

Passwords are disappearing.

Good.

Phishing-resistant authentication is one of the most important identity improvements enterprises can make.

But CISOs should resist turning that success into a false endpoint.

Because attackers do not care whether the enterprise calls itself passwordless.

They care about authority.

If they cannot steal the password, they can attack the session.

If they cannot steal the authenticator, they can attack the endpoint.

If they cannot compromise the user, they can compromise the machine identity.

If direct privilege is limited, they can traverse delegation.

If authentication is strong, they can manipulate what happens after authentication.

The target remains the same:

enterprise authority.

Black Hat USA 2026 demonstrated why the next generation of identity architecture needs to protect the entire chain:

Authentication
→ Session
→ Token
→ Delegation
→ Authorization
→ Execution

That gives us the central lesson of Part 8:

Phishing resistance protects the authentication ceremony. Identity security must protect the authority that survives it.

The post-password enterprise therefore needs a broader objective than passwordless authentication.

It needs:

phishing-resistant authentication,
replay-resistant sessions,
context-bound authority,
continuous trust evaluation,
governed machine identities,
visible delegation,
and rapid revocation.

Because the strongest authenticator in the world cannot protect an enterprise if the authority it creates can later be stolen, replayed, inherited or redirected.

The future of identity security is therefore not simply:

Passwordless.

It is:

Authority Assurance.

And that is a much larger architecture.

Publication Note & Disclaimer
This article provides security and governance analysis, not legal advice. Regulatory obligations must be assessed against the facts, jurisdictions, data types, and roles of the organizations involved.

This article reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.