Relationship Public Keys: The next Step for Passkeys

60-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

Passkeys have transformed how we sign into websites and apps. They're faster, more secure, and eliminate the need for passwords. But as more people use passkeys across multiple devices - their phone, tablet, and laptop - a new challenge has emerged.

Relationship public keys (RPKs) represent the next evolution in passkey technology. They solve a critical problem: how can websites trust that a passkey syncing across devices is still secure, without making users jump through extra verification hoops?

Think of it this way: when you create a passkey on your phone and then use it on your laptop, how does the website know your laptop is really yours? Traditional approaches often force users through additional security steps, defeating the seamless experience that makes passkeys so appealing.

Relationship public keys offer a smarter approach. This new technology lets passkey providers share trust signals between your devices, helping websites make better security decisions without frustrating legitimate users.

This article answers the following key questions.

1. How can websites trust synced passkeys without requiring extra verification steps from users?
2. What practical benefits do relationship public keys offer for industries like banking, healthcare, and fintech that need the highest security?
3. How should organizations prepare their systems for this emerging technology?

We explore how relationship public keys are improving passkey authentication through:

• Smarter security decisions based on device trust relationships
• Reduced friction for legitimate users while maintaining strong protection
• Enhanced compliance capabilities for regulated industries
• Future-ready authentication systems that adapt to evolving security needs

When passkeys sync across your devices, websites face a security dilemma. How can they be sure that the laptop using your passkey is really yours and not an attacker who somehow got access to your account?

To understand this challenge, imagine you create a passkey on your iPhone for your bank account. Later, you want to access your account from your MacBook. The passkey syncs automatically through iCloud Keychain, which is convenient. But from the bank's perspective, this creates uncertainty: is this MacBook really owned by the same person who created the passkey on the iPhone?

Today's solutions force an uncomfortable choice between security and user experience:

Maximum Security Approach: Some organizations require users to register a passkey on each device individually. This means going through verification steps (like SMS codes or email confirmations) every time you use a new device. While secure, it defeats the purpose of seamless passkey authentication.

Convenience-First Approach: Other organizations trust synced passkeys completely, accepting that some risk comes with the convenience. This works for certain industries but often is not suitable for banking, healthcare or other sensitive applications.

Compromise Solutions: Many organizations try to split the difference by requiring additional verification for "high-risk" actions on new devices. This creates inconsistent user experiences and often frustrates legitimate users.

You might think the solution is simple: just label each login as "secure" or "not secure." But this binary approach has fundamental flaws:

• Attackers can lie: If someone compromises your passkey account, they can make their device report false security information. A simple "secure/not secure" flag can be easily manipulated.
• The trust chain problem: To trust a new device, you need to trust an old device first. But how do you establish trust in the very first device? And what happens when that original device is lost or stolen?
• Context matters: A device might be trustworthy in one situation but not another. A work laptop might be secure for business applications but not personal banking.
• Too complex for websites: Every website would need to become an expert in device security, threat modeling and risk assessment. This isn't practical or scalable.

The challenge with trusting synced passkeys creates several practical problems:

• Limited enterprise adoption: Many banks and healthcare organizations are hesitant to fully embrace synced passkeys due to regulatory requirements, preferring device-specific authentication
• Inconsistent user experiences: Users face different security requirements across websites - some trust synced passkeys completely, others require additional verification steps
• Compliance complications: Organizations in regulated industries struggle to meet requirements like PSD2 Strong Customer Authentication while maintaining passkey convenience
• Conservative security policies: IT departments often implement overly restrictive policies to err on the side of caution, reducing the benefits of passkey adoption

The core issue is that the current all-or-nothing approach to trusting synced passkeys forces organizations to choose between security and user experience, limiting the full potential of passkey technology.

Relationship public keys take a fundamentally different approach. Instead of asking "Is this device secure?", they ask "Do we know this device has a trusted relationship with another device we already trust?"

Think of it like introducing a friend at a party. You don't need to know everything about your friend's background - you just need to know they're connected to someone you already trust. Relationship public keys work similarly for devices.

Relationship public keys work by allowing credential managers to establish and verify connections between devices. The exact methods for establishing these relationships are determined by the credential manager providers (like Apple, Google, or Microsoft), but the WebAuthn specification provides examples of what might constitute strong device relationships:

Physical Proximity: Devices verified to be in proximity using FIDO Cross-Device Authentication during or after credential manager sign-in. This could involve technologies like Bluetooth or NFC to confirm devices are physically near each other.

Shared Security Keys: Both devices signed into the credential manager with the same physical FIDO security key. This creates a cryptographic link between devices that used the same hardware token.

Phone Number Verification: For mobile devices, credential managers can verify in a phishing-resistant way that eSIMs are tied to the same phone number, providing stronger verification than traditional SMS methods.

The key insight is that these relationships are established and managed by credential managers, not by individual websites. The relationship public keys extension simply allows websites to see whether such relationships exist, without revealing the specific methods used to establish them.

These relationships create a "web of trust" between your devices that's much more sophisticated than simple security levels:

Transitive Trust: If your phone trusts your laptop, and your laptop trusts your tablet, then your phone can extend some level of trust to your tablet. This creates a network effect where legitimate users get increasingly seamless experiences across all their devices.

Degrading Trust: If a device hasn't been used in months or shows suspicious behavior, its trust relationships can be weakened or broken. This provides automatic protection against compromised or stolen devices.

Context-Aware Decisions: Different types of relationships can carry different weights. A device verified through physical proximity might be trusted more than one verified only through usage patterns.

This relationship-based model solves the fundamental problems of binary security levels:

Harder to Fake: An attacker would need to compromise multiple devices and establish fake relationships between them. This is exponentially more difficult than simply reporting "I'm secure."

Self-Healing: If one device in the web is compromised, the system can isolate it without affecting trust relationships between other devices.

Scalable: Websites don't need to become security experts. They just need to understand the simple concept: "devices with established relationships are more trustworthy than isolated devices."

User-Friendly: Legitimate users naturally create these relationships through normal device usage, while attackers would need to go to extraordinary lengths to fake them.

The technical implementation is simpler than it might sound. Relationship public keys work as an add-on to the existing passkey system that websites can choose to use. They don't replace regular passkeys - they enhance them with additional trust information.

Before diving into the implementation, it's important to understand what makes this possible:

Built on Existing Standards: Relationship public keys extend the WebAuthn standard that already powers passkeys. This means they work with existing infrastructure and don't require completely new systems.

Optional Enhancement: Websites can choose whether to request relationship information. If they don't ask for it, authentication works exactly like regular passkeys. If they do request it, they get additional trust signals to help make better security decisions.

Privacy-Preserving: The relationship information doesn't reveal personal details about users or their devices. It only indicates whether devices have established trust relationships, not what those devices are or how they're used.

Cryptographically Secure: Like passkeys themselves, the relationship information is protected by cryptographic signatures that can't be faked or manipulated by attackers.

When a website wants to check device relationships, it makes a simple request alongside the normal passkey authentication:

const cred = await navigator.credentials.get({
  publicKey: {
    challenge: ...,
    extensions: {
      relationshipPublicKey: true  /* Request device relationship info */
    }
  }
});

This tells the passkey system: "Along with the normal login, please also tell me about this device's relationships."

The process that follows is designed to be automatic and invisible to users while providing valuable trust signals to websites:

1. Automatic Creation: If this is the first time a device is being used, the system automatically creates a special "relationship key" for it. Users don't need to do anything - this happens seamlessly in the background.
2. Unique per Website: Each website gets its own relationship key, so your banking app can't see relationship data from your social media accounts. This ensures privacy while still providing useful trust information.
3. Selective Sharing: These relationship keys only get shared between devices that have proven they belong to the same person through one of the verification methods we discussed earlier (proximity, shared security keys, etc.).

Here's what actually gets communicated between the device and the website:

New Device Scenario: When a website sees a relationship key for the first time, it receives a signal that essentially says: "This device hasn't established trust relationships with any other devices that have accessed your site." This prompts the website to apply appropriate security measures.

Trusted Device Scenario: When a website recognizes a relationship key from a previous interaction, it receives a signal that says: "This device has a verified relationship with another device that has previously accessed your site." This allows the website to provide a smoother experience.

No Personal Information: Importantly, the website doesn't learn anything about what devices you own, where you are, or how you use your devices. It only learns about the trust relationships relevant to authentication decisions.

From a user's perspective, relationship public keys work invisibly:

• First Device: When you first create a passkey on any device, the experience is identical to today's passkey creation
• Additional Devices: When you use the passkey on other devices, the system automatically establishes relationships based on your setup process
• Ongoing Use: Once relationships are established, you get faster, more seamless authentication on trusted devices
• Security Events: If something suspicious happens (like a login from an unrelated device), you might see additional verification steps

First Time Seeing a Device: When a website sees a new relationship key, it knows this device hasn't established trust relationships yet. The website might ask for extra verification or apply additional security measures.

Recognized Relationship: When a website sees a relationship key it has seen before, it knows this device has a trusted connection to a previously verified device. The website can then provide a smoother experience.

For Users:

• Faster logins on trusted devices
• Fewer security pop-ups and verification steps
• Seamless experience across all your devices

For Businesses:

• Better fraud detection without user friction
• Compliance with regulations like PSD2 and HIPAA
• Reduced support costs from users locked out by security measures
• Higher conversion rates due to smoother authentication flows

Relationship public keys will transform authentication across industries, each with unique requirements and challenges.

Financial institutions have been cautious about synced passkeys due to regulatory requirements. Relationship public keys change this equation:

PSD2 Strong Customer Authentication: European banks must implement SCA for payments over €30. RPKs can help banks meet these requirements without forcing users through multiple verification steps on trusted devices.

Device Binding Requirements: Many banks require device registration for high-value transactions. RPKs provide cryptographic proof of device relationships, satisfying regulatory requirements while improving user experience.

Fraud Prevention: Banks can use relationship data to identify suspicious login patterns. A passkey used from an unrelated device might trigger additional verification, while related devices get seamless access.

Healthcare organizations struggle with balancing security and accessibility. Relationship public keys offer solutions:

HIPAA Compliance: Healthcare providers need strong authentication for patient data access. RPKs provide the necessary security assurance without creating barriers for medical professionals accessing records from multiple devices.

Emergency Access: In critical situations, healthcare workers need fast access to patient information. Trusted device relationships can enable rapid authentication while maintaining audit trails.

Multi-Device Workflows: Doctors often move between workstations, tablets, and mobile devices. RPKs can enable seamless transitions without compromising patient privacy.

Corporate environments have unique security and compliance needs:

Zero Trust Architecture: Many enterprises are implementing zero trust security models. RPKs provide additional signals for continuous authentication and device trust verification.

BYOD Policies: Companies allowing personal devices for work need strong device verification. RPKs can help distinguish between personal and corporate-managed devices while maintaining user privacy.

Privileged Access Management: For accessing sensitive systems, organizations can require devices with established trust relationships, adding an extra layer of security for critical operations.

Online businesses face the constant challenge of balancing security with conversion rates:

Checkout Optimization: High-value purchases often trigger additional verification. RPKs can reduce friction for users on trusted devices while maintaining security for new or suspicious devices.

Account Recovery: When users lose access to their primary device, RPKs can help verify that recovery attempts are coming from related, trusted devices.

Geographic Compliance: Different regions have varying authentication requirements. RPKs provide flexibility to apply appropriate security measures based on device trust and regulatory needs.

Organizations should evaluate their current state and prepare for relationship public keys:

Current Pain Points to Address:

• Where do users abandon flows due to excessive security steps?
• Which compliance requirements currently create user friction?
• How many support tickets relate to authentication and device verification issues?

Technical Preparation:

• Audit existing passkey implementations for RPK readiness
• Identify integration points with current identity providers like Amazon Cognito, Okta, or ForgeRock
• Plan for gradual rollout strategies that minimize disruption

Relationship public keys will have a great impact on the future of passkey security, but success requires a strong foundation today. Corbado helps organizations build this foundation and prepare for emerging authentication technologies.

The biggest challenge with relationship public keys isn't the technology itself - it's getting users to adopt passkeys in the first place. Even the most advanced RPK implementation is useless if only 10% of your users have passkeys.

This is where Corbado excels. Our platform is specifically designed to maximize passkey adoption through:

Smart User Experience Design: We've analyzed thousands of authentication flows to understand what makes users create and use passkeys. Our optimized flows can achieve 80%+ adoption rates.

Intelligent Nudging: Our system knows when and how to encourage passkey creation without being pushy. Users get gentle prompts at the right moments in their journey.

Proven Results: Companies using Corbado see dramatically higher passkey adoption compared to DIY implementations, creating the user base necessary for advanced features like RPKs to be valuable.

Many organizations worry about investing in new authentication technology only to have it become outdated. Corbado addresses this concern through our architecture:

Works With Your Existing Systems: Whether you use Amazon Cognito, Okta, ForgeRock, or another identity provider, Corbado integrates seamlessly. You don't need to rip and replace your current systems.

Automatic Updates: When relationship public keys become available, Corbado will update our platform to support them. You won't need to re-engineer your authentication system or wait for your legacy provider to catch up.

Standards-Based Approach: We build on open standards like WebAuthn, ensuring your investment remains valuable as the ecosystem evolves.

Understanding your users is crucial for relationship public keys success. Corbado's analytics help you prepare:

Device Usage Patterns: See how your users authenticate across different devices and operating systems. This data helps predict which users would benefit most from RPK technology.

Friction Point Analysis: Identify where users currently struggle with authentication. These pain points are prime candidates for RPK optimization.

Adoption Tracking: Monitor passkey creation and usage rates across user segments. High adoption rates ensure RPK features will have maximum impact when available.

Business Case Development: Use real user behavior data to build compelling business cases for advanced authentication features, moving beyond theoretical discussions to concrete ROI projections.

Ready to prepare for the future of authentication? Corbado makes it easy:

1. Quick Integration: Our SDKs and APIs integrate with your existing systems in hours, not months
2. Gradual Rollout: Start with a subset of users and expand based on results
3. Expert Support: Our team helps optimize your implementation for maximum adoption and success

The organizations that thrive with relationship public keys will be those that build strong passkey foundations today. Corbado helps you build that foundation while preparing for tomorrow's innovations.

Relationship public keys represent the next major evolution in passkey technology, solving critical challenges that have limited widespread enterprise adoption of synced passkeys.

In this blog post, we've answered the introduction questions as follows:

1. How can websites trust synced passkeys without extra verification? Relationship public keys create cryptographic "trust webs" between devices. When your phone and laptop have a verified relationship, websites can trust both devices without forcing users through additional security steps.

2. What benefits do RPKs offer regulated industries? Banking can meet PSD2 requirements while maintaining smooth user experiences. Healthcare organizations can satisfy HIPAA compliance without creating barriers for medical professionals. Enterprise environments can implement zero trust architectures with better user experience.

3. How should organizations prepare? Start by achieving high passkey adoption rates with proven platforms. Audit current authentication pain points and compliance requirements. Choose solutions that will automatically support RPK technology when it becomes available.

The organizations that succeed with relationship public keys will be those that build strong passkey foundations today. This technology promises to eliminate the traditional trade-off between security and user experience, creating authentication systems that are both more secure and more user-friendly.

By preparing now with platforms designed for future standards, organizations can position themselves to lead in the next generation of digital authentication - one where trust, security, and usability work together rather than against each other.