Passage retirement shows why authentication migration cannot wait

At a glance

What this is: This article argues that Passage’s retirement forces teams to migrate authentication infrastructure quickly and use the change to modernize passkeys, adaptive MFA, and orchestration.

Why it matters: It matters because authentication platforms sit on the human identity path, and delayed migration can expose production apps, disrupt sign-in, and create rushed changes that IAM and security teams then have to govern.

By the numbers:

• 16, ssage will be retired on January 16, 2026, giving teams about three months to plan, rebuild, and migrate.
• The platform has processed millions of passkey authentications, with passkeys making up 62% of authentication volume.

👉 Read Authsignal's guidance on migrating from Passage to a passkey and MFA platform

Context

Passage's retirement turns authentication from a product choice into a governance issue. When SDKs, APIs, and hosted services stop receiving updates, the question becomes how quickly teams can replace a live sign-in path without weakening assurance, user experience, or operational continuity.

For IAM leaders, this is a human identity migration problem with security consequences. The article frames passkeys, adaptive MFA, analytics, and orchestration as the capabilities that separate a stopgap replacement from a sustainable authentication stack, especially when production deadlines compress testing time.

Key questions

Q: How should security teams handle an authentication platform retirement without disrupting users?

A: Start with a complete dependency map of applications, SDKs, recovery flows, and admin paths, then rank them by business criticality and migration complexity. Preserve parallel run capability long enough to test passkey enrolment, fallback authentication, and session continuity. The goal is controlled cutover, not a rushed replacement that weakens access assurance.

Q: Why do passkeys still need adaptive MFA in enterprise IAM programmes?

A: Passkeys remove password replay and phishing risk, but they do not tell you whether a session is normal, risky, or fraudulent. Adaptive MFA adds runtime decisioning based on device trust, behaviour, and context. That keeps passwordless authentication usable while still allowing stronger challenges when the session deserves them.

Q: What breaks when authentication orchestration is missing during a migration?

A: Without orchestration, teams usually hardcode policy decisions into applications or duplicate them across channels, which creates inconsistent challenge logic and poor visibility. The migration may still work, but it becomes difficult to prove why a user was stepped up, which path was taken, or where friction is causing abandonment.

Q: What should IAM leaders evaluate before replacing a retired login platform?

A: Look beyond sign-in success and assess portability, auditability, fallback design, and long-term maintainability. A replacement should support current authentication methods, give you evidence of policy decisions, and avoid trapping recovery logic inside one vendor stack. If the architecture cannot survive the next product change, it is not truly future-ready.

Technical breakdown

Passkey migration in a retiring authentication platform

Passkeys replace reusable passwords with cryptographic authenticators bound to a user device and an origin. In a migration scenario, the technical challenge is not just enabling WebAuthn flows, but preserving account recovery, session continuity, and fallback paths when the legacy provider is being retired. If the old platform’s SDKs and APIs stop receiving security fixes, any unfinished integration becomes part of the attack surface. The practical question is whether the new stack can absorb traffic, recover from edge cases, and support multiple device states without forcing a redesign under deadline pressure.

Practical implication: Map every sign-in and recovery path before the legacy platform reaches end of support.

Adaptive MFA and risk-based authentication

Adaptive MFA changes authentication requirements based on signals such as device trust, location, user behaviour, and transaction context. This is different from static MFA because the policy is evaluated at runtime, allowing low-friction access for low-risk sessions and stronger challenges when risk rises. In a migration, this matters because teams often replace one login method with another but leave the step-up logic behind, creating a flat policy that cannot respond to changing conditions. The result is either excessive friction or a brittle control set that misses risky logins.

Practical implication: Define the risk signals that should trigger step-up before you decommission the old authentication path.

Identity orchestration, audit trails, and vendor lock-in

Identity orchestration sits above individual authentication methods and coordinates how they are combined, when they are triggered, and how exceptions are handled. Good orchestration also produces audit trails that show why a user was challenged, approved, or redirected. That matters in a migration because the organisation is not only replacing a login screen, it is preserving policy intent across systems. Without that layer, teams can move fast but lose visibility into fraud patterns, drop-off points, and control decisions, which makes ongoing governance much harder.

Practical implication: Treat orchestration and auditability as migration requirements, not optional enhancements.

NHI Mgmt Group analysis

Passkey migration is now an identity continuity problem, not a feature upgrade. When a core authentication service is retired, the enterprise inherits a hard deadline for preserving access, assurance, and supportability at the same time. That shifts the work from product selection to operational continuity, because the failure mode is not theoretical lockout but an unfinished cutover that affects production sign-in. IAM teams should treat retirement dates as governance milestones, not procurement reminders.

Adaptive MFA is the control that decides whether passwordless access stays usable under real-world risk. Passkeys can reduce credential replay and phishing exposure, but they do not remove the need for runtime policy decisions. The article’s emphasis on behaviour- and device-based challenges shows that authentication is now a layered decision problem, not a single factor choice. Practitioners should evaluate whether their current platform can step up risk without hardcoding every exception.

Identity orchestration is the named concept that separates a migration from a rebuild. A replacement platform that only reproduces login functions leaves teams with the same policy fragmentation they had before. Orchestration allows authentication logic, auditability, and method selection to remain coherent as methods change, which is what modern IAM programmes need when product lifecycles shift unexpectedly. The practical conclusion is to govern the flow, not just the factor.

Vendor retirement exposes the hidden cost of deferred authentication architecture decisions. Teams that built around a narrow passwordless service now have to decide whether they own integration complexity, observability, and fallback design. That is the real governance lesson: authentication strategy is only resilient when it remains portable across suppliers and can absorb lifecycle change without emergency engineering. Practitioners should judge platforms by operational survivability, not just enrolment simplicity.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• The operational lesson is clear in Ultimate Guide to NHIs , The NHI Market: lifecycle change should be treated as a governance event, not a last-minute migration task.

What this signals

Passkey migrations expose a broader identity lifecycle problem. Authentication platforms are often adopted as point solutions, then become embedded in production faster than teams can document their dependencies. When support ends, the programme has to absorb cutover risk, audit preservation, and user continuity at the same time, which is why identity architecture should be evaluated for exit paths as well as onboarding paths.

Identity orchestration will matter more as authentication stacks become multi-method by default. Teams are increasingly mixing passkeys, TOTP, push, OTP, and biometric options, and that complexity needs policy coherence rather than app-level one-offs. The organisations that can maintain consistent step-up logic across channels will have a cleaner governance story and less operational drift.

With 44% of developers reported to follow security best practices for secrets management, per The State of Secrets in AppSec, migration work that depends on scattered implementation habits will expose the weakest part of the authentication chain.

For practitioners

• Inventory every authentication dependency List all apps, SDKs, hosted flows, recovery paths, and admin consoles that rely on the retiring platform. Identify which journeys fail if updates stop, and assign cutover owners for each flow.
• Rebuild the migration plan around risk-based step-up Define which user behaviours, devices, and session conditions should trigger stronger authentication in the replacement stack. Test the policy with real traffic patterns before production cutover.
• Preserve audit evidence through the transition Make sure the new platform logs challenge decisions, authenticator changes, failure reasons, and fallback usage. Those records are essential for troubleshooting, fraud review, and access governance.
• Reduce future lock-in with portable identity design Prefer APIs, orchestration patterns, and integration layers that let you swap authentication methods without reworking every application. Keep recovery, enrolment, and step-up logic separate from application code where possible.

Key takeaways

• Authentication retirements are lifecycle events, not just vendor changes, and they can put production access at risk if teams delay planning.
• Passkeys reduce credential risk, but adaptive MFA and orchestration are still required to govern real-world sign-in behaviour.
• The safest migration strategy is the one that preserves auditability, portability, and fallback control after the old platform is gone.

Key terms

• Passkey Migration: The planned move from an authentication system that is being retired to a replacement that preserves user access and security controls. In practice, it includes enrolment, recovery, fallback handling, testing, and cutover governance, not just swapping one login method for another.
• Adaptive MFA: An authentication approach that changes the strength of verification based on risk signals such as device trust, behaviour, location, or session context. It reduces friction for routine logins while requiring stronger challenge steps when the session looks unusual or high risk.
• Identity Orchestration: The coordination layer that decides which authentication methods to apply, when to apply them, and how exceptions are handled across systems. It matters because it preserves policy intent and auditability when multiple login methods and application paths must work together.
• Fallback Authentication: A backup path used when the primary authentication method cannot be completed, such as device loss, enrolment failure, or platform migration. Good fallback design protects continuity without creating a weaker standing access path that attackers can abuse.

What's in the full article

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

• Comparative guidance on passkey, MFA, and orchestration capabilities for teams replacing Passage
• Implementation notes on integrating with AWS Cognito, Azure AD B2C, Auth0, and Keycloak
• Examples of no-code authentication rules and real-time analytics workflows
• Procurement and deployment details for teams planning a staged migration

👉 The full Authsignal post covers migration options, platform capabilities, and integration details for teams replacing Passage.

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 or maturing an IAM programme, it is worth exploring.