Agentic AI is outpacing security readiness. Passkeys still struggle with UX. Here are the five trends reshaping CIAM in 2026 and how to prepare.
How Apple broke "Sign in with Apple" with an unannounced and silent redirect
Between AI agents making autonomous decisions, passkey adoption hitting real-world friction, and enterprises demanding more control over their infrastructure, CIAM leaders face a fundamentally different set of challenges than they did even a year ago. The identity landscape is shifting faster than most organizations can keep up.
This post summarizes key insights from our recent fireside chat with Mickey Martin and Jeff Hickman. Watch the full webinar for deeper discussion, and real-world examples.
In this blog, we break down the five trends we see across customer conversations and deployment, and what it means for your identity strategy.
Google is making Etsy and Wayfair items shoppable through agentic AI search. Coinbase launched "Agentic Wallets" to give AI agents autonomous purchasing power. EMA Research recently found that agentic AI adoption is outpacing security preparedness at most organizations. The headlines are impossible to ignore and yet there's no consensus yet on how to manage identity for these non-human actors. Is it MCP? A2A? OAuth extensions? Something that hasn't emerged yet? The industry is still figuring it out.
While the protocols remain unsettled, the fundamentals of identity and access management haven't changed. Every agent needs an identity whether that's certificates, tokens, or something else. Every agent needs authorization attached to that human identity for accountability and auditability. And every agent acting on behalf of a user needs a mechanism to prove that the user actually consented. Just because we started throwing AI Agents into the flow does not mean we can get away without answering what action was taken, why it was taken, who initiated this action.
This isn't entirely new territory, either. The IoT era presented similar challenges when organizations didn't know whether Z-Wave, Zigbee, Lora, or Matter would win, and didn't know where to enforce authorization. Again, the core tenets remained the same: devices needed identities, authorization had to attach to those identities, and audit trails had to exist. The architecture shifted where things got enforced, but the fundamentals persisted. Agentic AI will follow the same pattern.
There is temptation to chase every new standard, especially when business stakeholders are pushing for AI capabilities. But building prototypes on shifting standards leads to constant rework. You build something, put it out, and a week later the entire thing's changed because the spec evolved. Organizations that build strong identity infrastructure around existing standards and frameworks such as OAuth 2.1, OIDC, SPIFFE, relationship-based access control (ReBAC), and PKI, will be better positioned regardless of which specific protocols eventually dominate. MCP's move to the Linux Foundation might suggest it has staying power, but that doesn't mean organizations should over-invest before the landscape stabilizes.
At the end of the day, agentic commerce is about generating revenue: how people buy, interact, and transact through agents. The payment processors are already moving; Mastercard and Visa are building frameworks. This commercial pressure will ultimately force standardization faster than technical consensus alone.
The other key issue most organizations haven't fully grappled with is scale. AI agents operate at machine speed, massively outpacing human interaction patterns. An organization with 100,000 human users might see millions of agent-driven identity operations. Traditional CIAM platforms designed for human-scale loads simply can't keep up, and this challenge cuts across authentication, authorization, and audit logging.
Passkeys were supposed to be the end of password problems. The technology is solid, cryptographically secure, phishing-resistant, and backed by every major platform vendor. So why are implementations still struggling?
Consider what happens every year when new phones drop. A significant percentage of users upgrade devices and immediately forget their passwords. Face ID, Touch ID, and fingerprint sensor data don't transfer between devices; each new device is a new authenticator from the application's perspective. This creates a predictable surge of password reset requests, frustrated users, and support burden. Worse, some users have accounts tied to email addresses they no longer control: old employers, defunct services, forgotten aliases. The recovery path breaks down entirely.
Passkeys solve this device portability problem because backup-eligible passkeys sync through cloud fabric such as Apple's iCloud Keychain, Google's credential manager, or third-party password managers like 1Password and Bitwarden. Users can authenticate on new devices without remembering passwords because the credential follows the user, not the device. This creates a two-factor authentication model by design: the biometric verification (something you are) plus the cryptographic credential (something you have). The device confirms the user's biometric, while the certificate provides stable cryptographic proof. Together, they create a strong signal without the password recovery headaches.
Platform behaviors vary significantly across platforms, and users encounter different prompts, different error states, and different recovery flows depending on their device and browser combination. Organizations have to design around these inconsistencies rather than assume the platforms will handle UX for them. Non-technical users get confused by credential management, struggle with cross-device scenarios, and need clear fallback paths when something goes wrong.
Will passwords disappear entirely? For CIAM, probably not, but they may become buried. Lower-risk applications might drop passwords entirely in favor of passkeys + magic links, while higher-risk applications like banking will likely keep passwords as one factor among many for recovery scenarios. The calculus differs by organization: some will decide they'd rather not hold password data at all because it represents ongoing liability, while others will keep passwords as break-glass mechanisms, similar to how some enterprises have historically treated them.
There's no going back to desktop-centric design. Users across all demographics expect seamless experiences whether they're banking, shopping, or checking results on their health chart, and the question isn't whether to prioritize mobile but how to do it well.
One of the most common UX failures occurs when a native app launches an embedded browser for authentication. Users experience this as jarring: they downloaded an app, but now they're looking at a browser window. That browser often doesn't have access to saved passwords or passkey credentials, sessions don't carry over from Safari or Chrome, and the experience feels broken even when it's technically working as designed. The frustrating reality is that 99% of the time, there's nothing the IAM team can do to fix this. Mobile operating systems intentionally isolate embedded browsers for security reasons, so the browser doesn't have access to the same keychain, the same stored credentials, or the same session state as the system browser or native app.
Progressive web apps deserve serious consideration as an alternative. Not every service needs a native app in the App Store. Progressive web apps deliver excellent mobile experiences, can be saved to home screens, and maintain consistent authentication state with the browser. They avoid the embedded browser trap entirely, and for many use cases, they're simply the better choice.
Native apps can access device-specific signals such as IMEI numbers, carrier information, device attestation that browsers cannot, and these signals enable additional identity verification and fraud detection. But the question organizations need to ask is whether those capabilities actually matter for their use case. If the answer is no, the complexity of native development and the UX pitfalls of embedded browsers may not be worth it.
Mobile users don't think in terms of sessions. They expect to open an app and be logged in. But security requirements, especially in regulated industries, demand periodic reauthentication and step-up authentication for sensitive actions. The organizations doing this well are invisible to their users because they've thought through session lifetime, step-up triggers, and graceful handling of network interruptions. The ones doing it poorly force users through unnecessary friction that damages both conversion and trust.
Enterprises are moving toward composable identity infrastructure, and the shift is being driven by a simple reality: organizations need to evolve their identity capabilities without ripping out what already works. Rather than multi-year platform migrations, teams are swapping and upgrading individual components in place. Need better passkey support? Add it. Want to integrate a new authorization model? Slot it in. CIAM is evolving incrementally as requirements change, and this modularity provides resilience too. If one component fails, core functionality continues, and organizations aren't dependent on a single vendor's uptime for everything.
At the same time, product teams are taking ownership of authentication UX in ways they didn't before. Generic login widgets and redirect-based flows don't cut it anymore. Teams want brand-consistent experiences across every touchpoint, which means they need APIs that let them build exactly what the business requires without template limitations or third-party UI constraints.
API-first architecture is winning because it gives teams the building blocks they need without locking them into predetermined flows. Well-designed APIs deliver flexibility that actually scales with requirements, enabling developers to implement exactly what the business needs, adapt as those needs change, and maintain full control over how identity gets handled across their systems.
Two related forces are reshaping infrastructure requirements for CIAM: expanding definitions of regulated data, and increasingly stringent sovereignty requirements.
Personally identifiable information (PII) isn't a fixed category. It's any data that can be used to distinguish a person. Recent rulings have clarified that email addresses count as PII in many jurisdictions, depending on how identifiable they are. An email like [email protected] is clearly PII; a random string might not be. This means data that organizations previously treated as non-sensitive may now fall under GDPR, CCPA, and other privacy frameworks, and the compliance burden expands with each clarification.
Data sovereignty used to be primarily about geo-redundancy and disaster recovery, but now it's about regulatory compliance, corporate security posture, and customer trust. Organizations need to know exactly where identity data resides, who can access it, and how it can be deleted. The right to be forgotten adds operational complexity. If data is spread across multiple systems and geographies, honoring deletion requests becomes a significant engineering challenge.
Organizations are also asking harder questions about their identity providers that go beyond data location to infrastructure itself: What happens if the underlying cloud provider has an outage? What happens if geopolitical constraints affect service availability in a region? What happens if the vendor itself goes away? These aren't hypothetical concerns. Organizations want fallback options, and even if they use SaaS identity today, they want to know they could self-host if necessary. This is driving renewed interest in solutions that offer deployment flexibility with options for cloud, on-prem, or hybrid.
Beyond GDPR, cross-border regulations can restrict where data lives and who can access it down to the support personnel who might see customer data during troubleshooting. Organizations operating globally need identity infrastructure that respects these constraints without creating operational nightmares.
Agentic AI creates new sovereignty questions that frameworks haven't fully addressed yet. If an AI agent is accessing EU citizen data to perform a task, where does that agent need to live? If it's a US-based agent processing EU data, what are the compliance implications? Organizations building agentic capabilities need to be thinking about these questions now, even without clear regulatory answers.
And then there's scale, again. API calls, service accounts, and AI agents are multiplying identity volume exponentially, and the scale that AI operates at massively outpaces humans. Organizations need infrastructure built for machine-scale loads from the start – not retrofitted later when the viral moment hits.
These trends reinforce each other rather than existing in isolation. The shift toward API-first architecture makes it easier to adapt to emerging standards for agentic AI. Modular infrastructure supports the flexibility needed for data sovereignty requirements. Mobile-first design patterns inform how organizations think about session management across all channels.
Agentic AI is already reshaping CIAM, and while the standards are unsettled, the use cases are here. Organizations should be thinking now about how AI agents will authenticate, what permissions they'll receive, and how their actions will be audited. The core identity tenets don't change but the scale and speed do.
Passkeys solve real problems around device portability and password fatigue, but implementation requires careful UX design across the full user base, not just early adopters. Organizations shouldn't treat passwordless as a solved problem.
If the mobile identity experience isn't where it needs to be, now is the time to invest. Consider whether native apps are actually necessary, or whether progressive web apps might deliver better UX with less complexity.
Whatever gets built today will need to evolve, so choosing modular, API-first infrastructure that supports incremental change without costly rip-and-replace projects is essential.
And even if self-hosted deployment isn't necessary today, organizations should make sure their architecture doesn't lock out that option tomorrow. Consider where AI agents will live and what data they'll access. Build for machine-scale loads from the start.
Re-shaping your CIAM stack? Contact us to learn more about how Ory can support your IAM strategy.
