Passkeys
Multi-device credentials
Phishing-resistant sign-in that syncs across a person’s phones and laptops. Ideal as the default for customers and staff.
Platform / Sign-in
Passkeys and Security Keys (WebAuthn)
WebFrolic supports WebAuthn (FIDO2) in two forms: passkeys, which are multi-device credentials that sync across a person’s devices, and security keys, which are single-device credentials that never leave the hardware. Administrators can use the FIDO Metadata Service to build AAGUID allow and deny lists, and upload their own root certificates to validate attestation from custom hardware.
Available now in WebFrolic.
Why it matters
Passwords are phished; passkeys are not. But not every passkey is the same device.
WebAuthn binds each credential to your domain, so a fake login page cannot capture it. A passkey synced through a consumer cloud account and a certified hardware key are both WebAuthn, though, and a regulated workforce often needs to know which one was used. WebFrolic keeps them apart and lets you decide.
Security keys
Single-device credentials
Phishing-resistant and device-bound: the private key never leaves the hardware. Ideal for administrators and privileged roles.
Model control
FIDO Metadata Service and custom roots
Build AAGUID allow and deny lists from the FIDO Metadata Service, and upload root certificates to validate attestation from your own hardware.
Two kinds of WebAuthn credential
Passkeys and security keys compared.
| Passkeys (multi-device) | Security keys (single-device) | |
|---|---|---|
| Where the credential lives | Syncs across the person’s devices through their platform or password manager. | Stays on one hardware key or device and cannot be exported. |
| Phishing-resistant | Yes | Yes |
| Device-bound | No | Yes |
| Several per user | Yes | Yes, so a spare key can be registered |
| Model restrictions | AAGUID allow and deny lists; attestation validation, including custom roots | AAGUID allow and deny lists; attestation validation, including custom roots |
| Typical use | Default sign-in for customers and employees | Administrators, privileged roles and regulated workloads |
Controlling which authenticators may enroll
AAGUIDs, the FIDO Metadata Service and attestation.
| Control | What it does | Use it when |
|---|---|---|
| AAGUID allow list | Only authenticator models whose AAGUID is on the list can enroll. | You issue specific keys, or policy names approved models. |
| AAGUID deny list | Blocks specific authenticator models from enrolling. | A model is unsuitable or has a known weakness. |
| FIDO Metadata Service | WebFrolic uses the FIDO Alliance Metadata Service list of authenticators and their AAGUIDs, so administrators can pick models to allow or deny instead of typing identifiers. | Building or reviewing either list. |
| Attestation validation | Checks the authenticator’s attestation statement at enrollment, and whether user verification (PIN or biometric) took place. | You need evidence of which hardware was used. |
| Custom root certificates | Upload your own root certificates to validate attestation from customized hardware security keys or devices. | Your company uses its own or customized authenticators that are not in public metadata. |
In the console
Set it up in four steps.
Menu names match the WebFrolic console. The setup guide has the detail.
Enable both authenticators
In Authenticators, enable passkeys and security keys, and scope each to the personas that should use them.
Choose models
On the security-key or passkey authenticator, build AAGUID allow or deny lists from the FIDO Metadata Service list.
Set attestation
Turn on attestation and user-verification validation, and upload custom root certificates for your own hardware.
Tie it to assurance
Raise the assurance level on privileged roles and applications so only the right WebAuthn credential satisfies them, then test enrollment, sign-in and replacing a lost key.
Before rollout
Questions worth answering.
Settle these first and the rollout is mostly configuration.
- Decide who may use passkeys and who must use security keys.
- Choose the authenticator models to allow or deny, and who maintains the list.
- Decide what happens when an authenticator returns no attestation.
- Make sure people can register a second key before enforcing a strict list.
- Upload root certificates for any customized hardware before rollout.
Related capabilities
Explore what connects to this.
These capabilities are usually configured together.
Evaluate with your scenario
Start with a concrete workflow.
Share the identities, resource boundary and decision you want to test. The walkthrough can focus on the relevant behavior rather than a generic feature tour.