If you’re like many others, you might be confusing syncing passkeys and Credential Exchange (CX). (Note: Device-bound passkeys are not affected by these specifications). Before we spiral into hypothetical doom scenarios, let’s get one thing straight: this is not about syncing. It’s not about making passkeys magically work across all your devices and all your platforms, like some universal login pixie dust. This is about something much more specific, much more niche, and arguably much more important for long-term user control and ecosystem interoperability.

Let’s talk about Credential Exchange (CX).

What is Credential Exchange

CX is a point-in-time migration protocol, not a sync protocol. If you’ve ever tried to leave one password manager for another, you probably remember the painful steps: exporting a CSV, crossing your fingers that nothing gets corrupted, and importing the file only to realize half your entries didn’t map correctly. Oh, and that CSV? Probably sitting unencrypted in your downloads folder.

The CX family of specifications was designed to fix that.

The CX family has both a schema specification and a protocol specification for securely moving passkeys (and other credentials and items you’d typically find in a credential manager) from one credential manager to another. Think: moving from Apple Passwords to Bitwarden, or Google Password Manager to 1Password. The goal is to eliminate the plain-text mess and standardize the fields so that you can actually preserve metadata like tags, notes, and usage history during a migration.

Again, because this keeps getting misunderstood, this is not a continuous cross-platform sync model. There’s no background process constantly pushing updates to different ecosystems. The user must initiate the migration from one credential manager to another. They can do this as many times as they want.

Why This Matters (Even if Most People Will Never Use It)

Let’s be honest: the regular person (hi, Mom!) will never touch CX. Most people will stick with whatever ecosystem their phone gives them—Apple, Google, whatever—and never think twice.

But for those who do care—those who worry about vendor lock-in, future-proofing access, or trust boundaries between providers—this matters a lot.

Imagine a world where:

• You’re done with Apple and want to move everything to 1Password.
• Your credential manager of choice is shutting down.
• You want to archive your credentials in a way your estate executor can actually access.

These aren’t everyday scenarios, but they’re real. And right now, they’re painful. CX gives us a clean, interoperable way to move between providers without compromising security (or sanity).

What Could Possibly Go Wrong?

Plenty. Like any tool, CX can be misused.

One of the concerns floating around is that CX could become another attack vector. Bad actors could convince users to “migrate” credentials to a malicious app, and if that app poses as a legitimate destination, it could harvest the user’s entire credential set. The threat model here isn’t fully defined yet—though it probably looks like how attackers already trick people into exporting or copying passwords from their managers—but it’s worth watching closely. OS platforms do have mitigations in place for dealing with malicious apps, before and after they are installed (e.g., Google Play Protect, app store review, etc), so mitigations are already in place.

From the relying party (RP) side, one of the issues here isn’t security as much as it is user experience and reliability. Some services today rely on hints from the credential manager (like “this credential lives in the Apple ecosystem”) to drive helpful UX choices. But once CX is in play, those hints can quietly become stale. A credential that once lived in one ecosystem may have been exported elsewhere, and the RP has no way of knowing. There are future plans to enable providing these hints when passkeys are used as well (not just during creation), which should alleviate these concerns.

This isn’t a CX design flaw. But it is a consequence of treating ecosystem-specific metadata as a proxy for where a credential lives, rather than what the protocol actually guarantees. As more users gain the ability to migrate their credentials, services that depend on these assumptions may need to rethink what “helpful” really means and how they rely on that information.

Security Model: New Questions, Not New Threats

CX doesn’t introduce a fundamentally new class of threats, but it does complicate the security model that many RPs and security teams have come to expect.

If CX has been used to export credentials, that same passkey may now live in a completely different ecosystem. There’s no standard way for RPs to tell whether a credential has moved or where it ended up. That makes it harder to scope the blast radius of an incident, and harder to know who still needs help.

There’s also the practical issue: most services haven’t built passkey rotation flows yet. Even if passkey re-registration is technically possible, very few RPs support it in production today. So when credentials are compromised and there’s no clear path to rotate them, users may fall back to less secure recovery options like SMS or email-based OTPs.

These aren’t dealbreakers. But they are operational challenges that need to be solved as CX gains adoption. If you’re building or maintaining a passkey-enabled system, now’s the time to think through:

• What happens when a credential manager is breached?
• Can you support credential rotation or re-enrollment?
• Are you depending on ecosystem hints that might no longer be valid?

Let’s Not Lose the Plot

Yes, there are risks. Yes, they’re worth discussing. But let’s be clear: not every use case demands the same level of security response, and not every theoretical vulnerability warrants panic.

CX is a tool, not a mandate. Its value depends on how and where it’s used. That’s why these questions about breach impact, credential portability, and fallback mechanisms must be addressed as part of a proper risk management exercise, not just tossed around as worst-case hypotheticals.

Threat modeling isn’t about imagining everything that could possibly go wrong. It’s about weighing likelihood, impact, mitigation, and business value. Treating CX as inherently dangerous because it introduces new questions is a shortcut to bad security decisions. Ask the questions, but do it in context. 

Why Not Just Call It “Migration”?

Honestly, that might’ve avoided a lot of confusion. CX as a name is technically accurate, but it doesn’t scream “this is only for rare migrations.” And unfortunately, consumer tech reporting has run with the idea that CX means passkeys can be synced across all providers, finally making good on the cross-platform dream.

That’s… not what this is.

It’s also not a get-out-of-jail-free card for people storing the same passkey across multiple providers. If one manager is compromised, that same credential may be reused elsewhere. Using CX doesn’t remove the passkey from the source. That’s still manual and must be done by the user if the user wants to avoid having credentials in multiple locations. The best practice, just like with passwords, is still to use one provider, close old accounts when you’re done, and avoid scattering credentials like breadcrumbs across the Internet. 

Bottom Line: This Is About Control, Not Convenience

Exportable passkeys, via CX, aren’t for your average user. They’re for those who want choice, who don’t want to be tied to a single vendor forever, and who want a standards-based path forward.

It’s not about making your credentials work everywhere. It’s about giving you a secure, private way to move them somewhere else when you’re ready to go.

It may not be a feature you ever use. But you’ll be glad it exists when you need it.

Thanks to Dean H. Saxe and many others for all their support in answering my questions and reviewing the post!

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

Author

Heather Flanagan is the Principal at Spherical Cow Consulting, helping organizations navigate the fast-moving world of digital identity and Internet standards. With 15+ years of experience translating complex technical concepts into clear, actionable strategy, she is known for bridging communities and guiding collaborative work. Heather currently co-chairs the W3C Federated Identity and Exploration Interest Groups, the IETF Secure Patterns for Internet Credentials (SPICE) working group, and HotRFC. Her past roles include leadership positions with the OpenID Foundation, IDPro, the IETF/IRTF, and REFEDS. Named to the 2025 Okta Identity 25 as a top thought leader in digital identity, Heather is a frequent speaker and writer focused on standards, governance, and the real-world friction of identity implementation. You can find more of her blog posts (and link to an audioblog podcast!) on her website at https://sphericalcowconsulting.com.

The post Passkeys and Credential Exchange appeared first on IDPro.

By Atul Tulshibagwale and Sean O’Dell

Security online is no longer a periodic snapshot of users and authorizations. We need an efficient architecture to respond to events and updates in real-time.

Background

Recently, Andi Hindle (of the Identiverse conference fame) and Ian Glazer (former SVP, Identity Product Management at Salesforce, and now President of Weave Identity) both published blog posts about how the area of identity and access management is changing to a more continuous model. 

• Andi’s blog: The Era of Continuous Identity
• Ian’s blog: Misalignment and the rise of Event-Time IAM

Earlier work around the Identity Fabric popularized by Gartner defines a framework for how different identity systems could collaborate to provide more complete security coverage for all constituent users and all protected systems. Among its “Must-Have” characteristics are things like “event-based integration connectivity” and “adaptive continuous, risk-aware and resilient security”. These also point to a continuous and event-driven methodology to ensure identity security…enter the concept of continuous security.

A Paradigm Shift

All this got us thinking: we’re seeing a paradigm shift in how we think about security. It’s a paradigm where there is no single point of control—each system needs to enforce its own access security—but you still need to define centralized policies and management.

Lately, the real security action has shifted to identity and the behavior of users. The specific concern here is whether that behavior represents legitimate usage or malicious behavior, either because an attacker has assumed a user’s identity or the user themself is deviating from what is or has been perceived as “normal”.

What does this mean when all your services run independently in a zero-trust architecture? There is no central point of control, other than the login-time participation of the identity provider. Like Ian said in his blog post, the “event-time” dimension comes in after you login, and this is what leads to the “Continuous Identity” state that Andi mentions in his blog.

What Is the Continuous Security Paradigm

So let’s consider a new model more suited to today’s dynamic security requirements: the Continuous Security Paradigm. As we move forward in identity, we are emulating behavioral characteristics from the real world in the digital realm. As an example, say you are having work done on your house and have contracted with a company. The company has notified you in advance that someone named Erik will arrive at a certain date and time to do the work.. When Erik shows up at the expected date and time, do you go back and verify if Erik is employed by the company doing the work? You probably don’t. Instead, you make a decision based on context and risk. You know to expect a person named Erik to be at your home between a certain time from a certain company to perform a task. This is exactly what zero-standing access is in the digital realm. Would you always grant Erik access to your home just because of this one task that they had to perform? No, that is too risky. These same principles are why the shift to a Continuous Security Paradigm is not only needed but required. 

The Continuous Security Paradigm is a system-centric view of security. Your particular application or system is one node in a tapestry of loosely coupled nodes. In addition to the usual data plane and control plane, this paradigm introduces a new “Signals Plane” of asynchronous communication, which enables event-time processing. Runtime decisions are, as expected, made in the Data Plane, but they are based on the context derived from the Signals Plane. The Control Plane defines the trust topology of the Signals Plane.

The Control Plane

Rather than viewing the network as a uniform “fabric”, the Continuous Security Paradigm models it as a loosely coupled and more diverse tapestry that captures the differences in how much each node trusts another, and who owns individual nodes. A node in such a network is not about physical or virtual connectivity as represented by Virtual Private Clouds (VPCs) or firewalls, but a logical definition of what information is asynchronously communicated (either received or transmitted) between which nodes in the tapestry. This may include nodes that you “own”, e.g., VPCs, SaaS tenants, or IaaS tenants, but it may also contain nodes that are trusted sources of public information (e.g., public securities data or dark web credential monitoring data).

The control plane is used to specify this trust topology. Specifically, how each node is connected to another with respect to the trust, entities, and attributes. For example:

1. A CRM node trusts the HR node as the authoritative source for employee entities and their attributes such as their cost center.
2. An application node trusts the HR node as an authoritative source for employee entities and trusts the CRM node as the authoritative source for customer entities and as a non-authoritative source for employee entities, which it correlates with the authoritative employee entity source, the HR node.
3. The CRM node trusts the application node to receive customer entities and certain attributes of customer entities from it.
4. The HR node trusts the CRM node and the application node to receive employee entities and specific attributes of those entities.

The control plane also specifies the frequency of ingestion or transmission of specific entities to / from specific nodes. It also specifies the policies to be applied when using information received from other nodes.

The Signals Plane

The signals plane enables each node to asynchronously collect the entities and attributes that are important to its own data-plane decisions. It also enables each node to communicate any changes to its entities and attributes that may be relevant for other nodes it trusts. The asynchronous ingestion and transmission of trusted data enables each node to decouple its runtime decisions from the availability and latency characteristics of other nodes in the network. Open standards such as the OpenID Shared Signals Framework (SSF) are designed for conveying such information asynchronously.

The Data Plane

The actual access decisions in response to API calls or user requests are done in the data plane. The signals plane enables each node to ensure that it or other nodes in its network do not make decisions based on outdated information. Yet, because the information is conveyed asynchronously, the decisions each node makes are based on “event-time”, or “continuously updated” information – without sacrificing efficiency. When a data plane event occurs, e.g., a user attempts to access specific data in a node, the policies specified by the control plane govern how the asynchronously ingested data and the runtime data from the data plane are used to make decisions.

Computation in CSP

To ensure security for an application, e.g., one node in your organization’s network, you need to:

1. Obtain trusted signals about all interesting interactions/events (identities, devices, environmental factors (e.g., IP location, geo-location, etc.). Some signals are obtained from the user request, but most may be obtained asynchronously using the signals plane from other nodes
2. Make your own policy decisions about granting or denying access: Your application or system needs to have its own rules to determine access and know user behavior as far as your own application is concerned
3. Communicate changes to other nodes: The control plane may obligate you to communicate any changes to certain entities to other trusted nodes, at a certain cadence. Doing this enables all nodes to make decisions based on event-time data.

Why introduce a new paradigm?

We’re seeing escalating tensions on a couple of axes: Between having to constantly re-evaluate access decisions, the desired performance, and the computational impact of doing so; and between the independence and resilience of each system and the enforcement of common policies. The Continuous Security Paradigm enables independent, decoupled execution while being able to leverage the latest data, and one that enables real-time decisions without huge availability and performance requirements. It also enables independent services to be good citizens of a larger network that can both help other services make good decisions and be a part of a common trust topology.

Managing a Continuous Security Paradigm-based Network

Even though each node operates independently in terms of the decisions it makes, your organization needs to centrally manage the trust topology between various nodes and the policies that you need to comply with within each application or system (e.g., within each node). A centralized management system can use the control plane to set the rules. This is different from a central point of control for each access decision. At the same time, each node is free to dynamically modulate the trust it places in systems it receives data from, based on the quality of signals it receives from them. Diagrammatically, this can be represented as follows:

In the diagram above, all types of systems, including SaaS apps, cloud infrastructure, custom apps, and APIs, follow the same continuous security paradigm. 

• All of them consume signals from other systems, make access decisions for themselves, and selectively convey signals to other systems. This is the new “signals plane” of asynchronous communication that is disjoint from the data plane or the control plane
• An organization would, of course, need to manage trust between various systems (internal or external) and would need to set org-wide contextual rules. That is provided by the control plane described by the long rectangle at the top of the diagram.
• Finally, the systems need to respond to inline requests from the client, regardless of whether the client is a robotic principal or an end-user. Access decisions need to be made for each one of these requests. This is the data plane.

Looking Ahead: The Continuous Security Paradigm in Practice

Where do we begin?

The CSP includes components that may be within your control (such as custom apps) and some that you will need support from (e.g. SaaS apps). However, keeping this paradigm in mind as you build out your strategy is key. You might find solutions that help you realize parts of this picture, and you can influence others in moving to support this architecture. For instance, building out a signals plane by adopting the OpenID Shared Signals Framework can help build out the context for your existing components – whether they are SaaS apps or custom apps.

Use Cases

The big picture here offers a way for cybersecurity and identity practitioners to think about securing systems and services in a way that supports real-time considerations. In our next blog post, we’ll break this down and discuss specific use cases where continuous security paradigms can be used today and the standards that already support this model.

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

Authors

Atul Tulshibagwale is the CTO of SGNL, a company backed by Microsoft and Cisco and founded by ex-Googlers that helps enterprises mitigate damage from identity breaches. Named in the Okta “Identity 25”, Atul is a federated identity pioneer and the inventor of the Continuous Access Evaluation Protocol (CAEP). He was previously at Google, where his seminal blog post kicked-off the industry-wide movement that culminated in the OpenID Foundation’s Shared Signals working group, which he co-chairs. Atul is also a Corporate Board Member of the OpenID Foundation. His leadership in developing and promoting SSF and CAEP, the critical zero-trust standards, has been influential in their widespread adoption. Apple, Okta, Cisco, and others have announced support for these standards. Previously, Atul was a co-founder and the CEO of Trustgenix, a federated identity pioneer that was acquired by HP. Trustgenix contributed to the development of federated identity standards such as SAML 2.0 and the Liberty Alliance Framework.

Sean O’Dell is a Senior Staff Security Engineer spanning both Consumer and Workforce IAM at The Walt Disney Company. He is a co-chair of the Shared Signals Working Group in the OpenID Foundation and has been on podcasts covering identity security and written about the subject…with more coming soon. He is a technical leader and trusted technical advisor to executives at The Walt Disney Company where he has been instrumental in both Workforce and Consumer IAM strategy over the past 10 years covering security, product, engineering, implementation, and architecture while also acting as a principal advisor in the same capacity for key mergers and acquisitions helping to shape overall company decisions and direction. His vision, leadership, and implementation expertise are helping to promote and drive the adoption of both SSF and CAEP overall in the industry. His current focus around identity security is zero standing privilege, next-gen authorization, ITDR, shared signals, CAEP, behavioral analysis, data science, identity data…all of the continuous aspects of identity security.

The post The Continuous Security Paradigm appeared first on IDPro.

Identity and Human Rights

The Universal Declaration of Human Rights enshrines the concept of recognition as a person before the law as a fundamental human right. Digital identity is a new aspect of that fundamental right, a topic covered by Elizabeth Garber and Mark Haine in the white paper “Human-Centric Digital Identity: for Government Officials.” This right has also inspired the United Nations Development Programme (UNDP) Model Governance Framework for Digital Legal Identity System. 

Source: UNDP Digital Legal ID Governance website – https://www.governance4id.org/ 

Digital Identity and the United Nations

It might seem like a big stretch to go from our day-to-day worries about our IAM systems to a governance framework designed for governments worldwide to adapt as they build their digital identity programs, but it’s happening. The UNDP argues that there is a significant social and economic benefit for governments to digitize their identity programs and close the identity gap. Just in financial services alone, a strong digital public infrastructure is expected to speed up growth by 20-33%. 

Think about it. Our little corner of the world, which focuses on a specialty so young you almost certainly don’t have a degree in it, is now a core aspect of global economic growth!

Eight Core Themes

So, what does the UNDP’s framework look like? As expected of the UN, they are taking a broad approach that considers all elements of society. Specifically, they offer guidance on:

• Equality and Non-Discrimination
• Accountability and the Rule of Law
• Legal and Regulatory Framework
• Capable Institutions
• Data Protection and Privacy
• User Value
• Procurement and Anti-Corruption
• Participation and Access to Information

The UNDP model comes from their legal identity AND digital public infrastructure efforts, which is the right combination of organizations to bring together. Digital transformation is a bit of a buzzword, and yet, that’s what is happening. The UNDP is trying to help provide some guidance so countries are at least somewhat going in the same direction. They’ve already noted that there are at least as many failed identity programs as successful ones, usually because of inadequate governance. 

Digital identity always comes down to governance.

Applying the Framework

We can always learn from others, and we have an opportunity, regardless of what sector we work in, to learn from the UNDP framework. While targeted towards governments and civil society, there is quite a bit here that the public sector can apply to their IGA programs. The need to take into account as a foundational principle the need to support equity and diversity is one example. Another is ensuring the systems and programs are adequately funded and clear of undue influence. 

Wrap Up

So why is this a Letter from Leadership post (which we’re also posting to the blog)? Because identity governance is our space and everyone in this organization has an opportunity to be a leader in ensuring the identity programs they are part of are well-designed and developed. So, as one leader to the next (that’s you), I hope you take a few moments to think about this bigger picture and how you can make the governance of the identity systems around you better.

Author

Heather Flanagan, Acting Executive Director and Principal Editor for IDPro (and Principal at Spherical Cow Consulting) comes from a position that the Internet is led by people, powered by words, and inspired by technology. She has been involved in leadership roles with some of the most technical, volunteer-driven organizations on the Internet, including the IETF, IAB, and IRTF as RFC Series Editor, ICANN as a Technical Writer, and REFEDS as Coordinator, just to name a few. If there is work going on to develop new Internet standards, or discussions around the future of digital identity, she is interested in engaging in that work.

The post Identity and Human Rights appeared first on IDPro.