Authentication is moving from control ownership to trust orchestration

At a glance

What this is: NHI Mgmt Group's analysis, drawing on OneSpan's blog post: Authentication is shifting from controlling individual factors to orchestrating trust across platform-mediated credentials, wallets and runtime signals.

Why it matters: IAM teams need to reassess how assurance is decided at runtime because passkeys and delegated identities change where trust is evaluated, not just how users sign in.

Context

Authentication is moving beyond the old model where security teams could treat passwords, OTPs and identity proofing as controls they directly owned. The governing problem is now trust evaluation, because platform-mediated credentials change where assurance is established and how it is consumed.

For human IAM programmes, that means the control point shifts from static policy settings to runtime decisions across credential type, platform mediation and contextual risk. The article also points to delegated AI identities as the next step, where the same trust orchestration problem extends beyond human sign-in.

In practice, this is not a question of whether authentication still matters. It is a question of how assurance is composed when the browser, operating system, wallet or agent now participates in the trust decision.

Key questions

Q: How should IAM teams adapt authentication when passkeys and wallets mediate trust?

A: IAM teams should move from factor-centric policy to assurance-based decisioning. That means classifying credentials by trust level, checking the platform or wallet that presents them, and using runtime signals to decide whether the session deserves high-risk access. The goal is not more checks, but better trust composition at the moment of authentication.

Q: Why do over-the-top authentication methods fail against phishing and relay attacks?

A: They fail because the attacker can bypass the method rather than break it. Passwords, OTPs and similar controls often authenticate the user without strong binding to the device, app origin or platform context, so phishing and real-time relay can reuse valid credentials inside an adversary-controlled flow.

Q: What breaks when authentication and authorization are treated as the same control?

A: Teams lose visibility into whether the real problem is identity proof or permission scope. That leads to weak remediation, because fixing login assurance does not reduce access blast radius, and tightening roles does not stop bad authentication. Mature IAM programmes separate the two so they can measure, govern, and audit them independently.

Q: What is the difference between credential verification and trust orchestration?

A: Credential verification asks whether the presented factor is valid. Trust orchestration asks how much confidence the organisation should place in that credential, the platform presenting it and the surrounding runtime signals before granting access. The first is a validation step; the second is a decision model.

Technical breakdown

Why over-the-top authentication broke down

Over-the-top authentication describes methods that operate independently of the underlying platform, such as passwords, OTPs and selfie-based checks. The weakness is not only weak policy, but weak binding: the method is accepted without strong assurance about device, origin or runtime context. That is why phishing, real-time OTP relay and adversary-in-the-middle attacks succeed without defeating the policy itself. Security teams often focus on operating the factor, but the deeper issue is that the factor is not rooted in the environment that is actually executing it. Practical implication: stop treating policy ownership as control ownership when the trust decision is detached from the platform.

Practical implication: stop treating policy ownership as control ownership when the trust decision is detached from the platform.

How platform-mediated credentials change trust evaluation

Passkeys, digital credentials and identity wallets move authentication into platform-mediated flows. The operating system, browser and wallet mediate how the credential is presented, while apps call that capability through APIs. This changes the security model because the app no longer directly inspects the full assurance context. Instead, it must infer trust from the credential type, the wallet, the platform and the surrounding device signals. That is a different decision problem from password verification or traditional document checks. Practical implication: design authentication logic to compare assurance levels, not just to accept or reject a login event.

Practical implication: design authentication logic to compare assurance levels, not just to accept or reject a login event.

What delegated identities mean for authentication governance

Delegated AI identities extend the same shift from direct control to trust orchestration. The article's important point is not that AI is automatically autonomous, but that execution is increasingly mediated through platform layers the organisation does not fully own. That means the question changes from who authenticated to who is acting, under whose authority and within what constraints. Human IAM assumptions that a user is the only actor behind a session start to weaken when software actors can inherit or present authority through the platform. Practical implication: treat delegated execution as an identity governance problem, not only an application security problem.

Practical implication: treat delegated execution as an identity governance problem, not only an application security problem.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trust orchestration is replacing control ownership as the real authentication problem. Authentication teams used to optimise policies they directly operated, but that model assumes the control surface sits inside the application boundary. Once passkeys, wallets and platform APIs mediate the decision, the real task becomes deciding how much trust to assign to a presented credential and its execution context. Practitioners should read this as a governance shift, not a UI refresh.

Credential assurance is no longer a single attribute. A device-bound security key, a synced passkey and a government-issued digital credential do not carry the same trust weight. The article correctly points to a multi-signal decision model in which credential type, wallet trust, platform health and runtime context all influence the final authentication outcome. Teams that collapse those differences into one binary factor are flattening assurance into noise.

Authentication policy is becoming platform governance by another name. When the browser, operating system or wallet participates in the trust decision, the programme has to care about the platform's behaviour, not just the identity proofing step. That broadens responsibility across human IAM, device trust and application risk signals. The implication is that authentication architecture must be designed as a composed trust stack, not as a single control.

Delegated identity exposes the limits of human-centric session assumptions. The same trust orchestration logic that applies to passkeys will soon apply to software actors presenting or inheriting authority. Human IAM frameworks often assume a person is the stable subject of authentication, but platform-mediated delegation makes that assumption less durable. Practitioners should prepare for an identity model where authority is evaluated continuously across user, device, wallet and delegated execution paths.

Named concept: trust orchestration. This article sharpens a useful term for the market: trust orchestration is the runtime composition of credential assurance, platform confidence and contextual signals into one decision. It matters because security no longer lives in the factor alone, but in how the platform, the wallet and the application agree on acceptable trust. Teams should align governance to that composition, not to isolated factor ownership.

What this signals

Trust orchestration is the programme-level shift IAM teams need to absorb. The old habit of treating authentication as a set of controls to operate creates blind spots once the trust decision is split across wallet, platform and application layers. Teams should reframe authentication architecture as a decisioning problem, where assurance is composed dynamically rather than inherited from a single factor.

Passkeys may be the first visible sign of the change, but delegated software actors point to the deeper consequence: identity governance will increasingly need to understand who or what is acting, under which authority, and with what runtime evidence. That is a broader programme change than MFA modernisation, and it affects policy, telemetry and access design together.

For practitioners

• Redesign authentication policy around assurance tiers Classify credential types by assurance level, including device-bound security keys, synced passkeys, wallets and self-asserted credentials. Use those tiers to drive risk decisions at runtime rather than applying one flat authentication policy to every login path.
• Inventory where trust is actually evaluated Map whether the browser, operating system, wallet, app or identity provider is making the trust decision, then identify where the current programme still assumes direct control. That gap is where authentication governance usually breaks down.
• Reduce dependence on noisy device fingerprinting Replace brittle fingerprint collections with fewer signals that better distinguish a legitimate user from a hostile bot, adversary-in-the-middle flow or delegated actor. Focus on signals that survive platform mediation and can be defended operationally.
• Prepare governance for delegated execution Define how the organisation will evaluate software actors that act under delegated authority, especially where identity assertions are mediated by platform services. Human login rules will not be enough once execution paths become shared across people and software.

Key takeaways

• Authentication is moving toward runtime trust decisions that combine credential type, platform mediation and contextual signals.
• Passkeys and digital credentials do not eliminate governance work, they relocate it to assurance composition and decision quality.
• IAM programmes that still assume direct control over every factor will struggle as delegated identities and platform-mediated flows expand.

Key terms

• Trust Orchestration: Trust orchestration is the automation of certificate, key, and secret lifecycle work across deployment pipelines and operational systems. It links issuance, renewal, verification, and rollback into one controlled flow so machine identities behave consistently at scale.
• Platform-Mediated Authentication: Authentication in which the operating system, browser, wallet, or secure hardware mediates credential use instead of the application handling the exchange directly. This changes the trust boundary because the app consumes platform signals rather than validating every mechanism itself.
• Over-the-Top Authentication: An authentication method that operates independently of the underlying device or platform context, such as passwords, OTPs or older identity proofing flows. These methods can be widely deployable, but they often lack strong binding to the app, device or origin that actually used them, which weakens trust evaluation.
• Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.