Authentication is moving from control ownership to trust orchestration

At a glance

What this is: This is an analysis of how authentication is moving from directly operated controls to platform-mediated trust decisions, with passkeys and delegated identities as the clearest examples.

Why it matters: It matters because IAM teams now have to govern trust decisions across credential types, platforms, and runtime signals instead of assuming control at the application layer.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read OneSpan's analysis of trust orchestration in modern authentication

Context

Authentication is increasingly platform-mediated, which means the security decision is no longer made only by the application that consumes the credential. The primary IAM question becomes how much trust the platform, wallet, or device should carry at runtime, especially as passkeys and digital credentials replace older over-the-top methods.

For identity programmes, this is a governance change as much as a technology change. Human authentication, NHI credentials, and delegated software actors all depend on trust evaluation that crosses device state, issuer assurance, and contextual risk signals, so the operating model has to move beyond static policy enforcement.

Key questions

Q: How should security teams govern authentication when credentials are platform-mediated?

A: Security teams should treat platform-mediated authentication as a trust evaluation problem, not just a sign-in problem. Define which platform signals count toward assurance, distinguish between credential classes, and make runtime policy depend on issuer, device state, and context. The application should consume trust signals, not assume the platform alone resolves risk.

Q: Why do passkeys improve security but still require IAM governance?

A: Passkeys improve security by reducing phishing and secret theft, but IAM governance is still required because identity risk moves to enrollment, device trust, and recovery. If those processes are weak, the organisation can still suffer account takeover through the path around the passkey rather than through the passkey itself.

Q: What do security teams get wrong about authentication controls and trust?

A: They often assume that operating a control is the same as controlling trust. In practice, phishing, relay attacks, and delegated access can bypass or reshape the control path entirely. The mistake is treating credential policy as the whole security model rather than one input to a broader trust decision.

Q: Who should be accountable for AI identity governance?

A: Accountability should sit with the team that owns the workflow and the team that owns identity controls, because AI access crosses both domains. Security, platform, and application owners each hold part of the lifecycle, but one business owner must remain responsible for the access decision and its removal.

Technical breakdown

Platform-mediated authentication and trust boundaries

Passkeys and digital credentials shift authentication into the operating system, browser, or wallet layer, where the platform mediates credential use through APIs. That changes the trust boundary because the app no longer directly validates every element of the exchange. Instead, it depends on platform signals such as device health, origin, and secure hardware protections. This is why phishing resistance improves, but also why the trust decision becomes less visible to the application owner.

Practical implication: IAM teams must define which platform signals are authoritative before they can treat a credential as high assurance.

Credential assurance is now context-sensitive

A credential is no longer just a yes or no authentication event. Assurance depends on whether the credential is device-bound, synced, wallet-issued, or self-asserted, and whether the surrounding environment appears trustworthy. That is a different model from passwords or OTPs, where the control existed primarily as a static rule set. Modern authentication has to compare credential types and surrounding conditions in real time, then convert those inputs into a consistent decision.

Practical implication: access policies should distinguish among credential classes rather than applying a single assurance level across all sign-in methods.

Delegated identity turns authentication into trust orchestration

The same pattern extends into delegated AI identities. If a software actor can act under a user’s authority, the critical question is not only who authenticated, but who is acting and under what constraints. That introduces a trust orchestration problem spanning credential, platform, and delegation context. This is where traditional authentication logic starts to fail, because the unit of trust is no longer just the login event.

Practical implication: identity architecture must account for delegated execution paths, not only human login flows.

NHI Mgmt Group analysis

Authentication control ownership is giving way to trust orchestration. The old model assumed that if the enterprise defined the authentication levers, it controlled the outcome. That premise breaks when platform APIs, credential wallets, and device-mediated flows sit between the app and the credential. The implication is that IAM governance now has to assess trust across layers the application does not directly control.

Credential assurance is becoming a comparative governance decision, not a binary check. Device-bound credentials, synced passkeys, government credentials, and self-asserted identifiers do not deserve identical treatment. Their assurance levels differ because their issuance, storage, and presentation contexts differ. Practitioners need a model that compares trust classes instead of flattening them into a single authentication policy.

Trust orchestration is the right named concept for the shift this article describes. It means making runtime decisions by combining credential assurance, platform trust, and contextual risk into one operating model. That concept matters because future authentication is less about controlling the credential itself and more about governing how trust is assembled at the moment of use. IAM teams should treat this as an architectural transition, not a UX upgrade.

Delegated AI identities extend the same trust problem into software execution. Once an agent can act under delegated authority, the question is no longer only identity verification, but authority propagation across software actors. The result is an authentication model that must accommodate both human and non-human actors without assuming a fixed operator behind every action. Practitioners should rework governance for delegation, not just sign-in.

Residual risk still demands application-level self-defense. Platform controls reduce certain threats, but they do not eliminate malware, adversary-in-the-middle attacks, or impersonation risk. Applications still need telemetry and protective signals that help distinguish legitimate use from hostile activity. The practical conclusion is that platform trust must be complemented, not replaced, by application-side verification.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• That same governance gap is why the 52 NHI Breaches Analysis remains a useful reference for lifecycle failure patterns.

What this signals

Trust orchestration: the practical issue is not whether authentication becomes more secure in isolation, but whether IAM programmes can evaluate trust consistently across human credentials, platform-mediated credentials, and delegated software actors. Teams that still rely on a single policy layer will struggle to distinguish high-assurance sessions from merely successful ones.

With 30.9% of organisations storing long-term credentials directly in code, per the Guide to the Secret Sprawl Challenge, the boundary between authentication and secret governance is already blurred in practice. That is why organisations need a broader operating model that combines identity assurance with lifecycle control and runtime monitoring.

As passkeys and delegated identities spread, the programme signal to watch is whether access decisions can still be explained in terms of issuer, platform, and context. If they cannot, the authentication layer has become opaque enough that governance, audit, and incident response will all slow down.

For practitioners

• Define credential assurance tiers Classify device-bound credentials, synced passkeys, wallet-presented credentials, and self-asserted identifiers separately, then map each to an explicit assurance level for authentication policy.
• Inventory platform trust signals Document which device, browser, wallet, issuer, and secure hardware signals your applications can actually consume through platform APIs.
• Redesign access decisions for delegation Update IAM governance so software actors acting under delegated authority are evaluated for constraints, origin, and runtime context, not only for successful sign-in.
• Keep application self-protection in the model Retain telemetry, anomaly detection, and risk-based checks inside the application so platform-mediated authentication does not become the only control boundary.

Key takeaways

• Authentication is shifting from direct control ownership to runtime trust evaluation across platforms, credentials, and devices.
• The practical risk is not only phishing resistance or passkey adoption, but whether IAM teams can still explain why a session was trusted.
• Identity programmes need explicit assurance tiers, delegation boundaries, and application-side signals if they want to govern the next authentication model.

Key terms

• 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.
• 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.
• 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.
• Authentication Assurance: The degree of confidence that an identity has been verified to the intended standard before access is granted. For MFA, assurance depends on the whole enforcement chain, including session handling, retry policy, and telemetry, not merely the presence of a code prompt.

What's in the full article

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

• The platform and wallet trust model behind passkeys and digital credentials in production flows
• How banks should compare assurance across credential types and issuer ecosystems
• The role of device state, page origin, and secure hardware in runtime trust decisions
• Why delegated AI identities change the authentication operating model for enterprise apps

👉 OneSpan's full article covers the shift from control ownership to delegated trust decisions in more operational detail.

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 identity controls across human and non-human systems, it is worth exploring.