Beyond Identity began deployment of a new Secure Work software release on August 8, 2026.
Early Access: FIDO2 / WebAuthn Security Keys
FIDO2 / WebAuthn security key support ships in this release as an early-access feature. It is enabled per tenant rather than on by default — reach out to support to have it turned on during your next maintenance window. Because it is still early access, the behavior described below may change before general availability.
| Feature | Feature Description |
|---|---|
| Sign In with a FIDO2 Security Key | Users can now authenticate with a FIDO2 security key or a built-in platform authenticator — Face ID, Touch ID, Windows Hello, or Android biometrics — directly in the browser, with no Platform Authenticator installed. Administrators enable it by selecting the new Platform Authenticator + FIDO2 authenticator configuration for an application, so a single application can offer both sign-in methods side by side. FIDO2 sign-in works from the Hosted Web Authenticator, from an application’s own configured sign-in domain, and from the Support Console. |
| Control Which Keys Your Users Can Register | A new FIDO2 section in the authenticator configuration dialog sets Authenticator Attachment: Platform (Face ID, Touch ID, Windows Hello, Android biometrics), Cross-Platform (portable USB, NFC, or Bluetooth keys such as YubiKey), or Either. Registration is restricted to device-bound keys — passkeys that a platform would sync to the cloud across a user’s devices are rejected at registration, so a credential cannot leave the device it was created on. |
| Require User Verification | A new setting, on by default, requires the security key itself to verify the user — with a PIN, biometric, or equivalent — before it will sign. It is enforced by the Beyond Identity service rather than only requested of the browser, so a key that skips verification is rejected rather than silently accepted. |
| Roaming Authentication Settings per Application | Roaming authentication — including its allowed-IP list and unknown-user handling — is configurable from the authenticator configuration dialog and is honored per application at sign-in. It is hidden from the default platform configuration so it appears only where it applies. |
| Users Can Enroll Their Own Security Keys | End users can register a FIDO2 security key for themselves from the user console — either from the passkey list or through an emailed enrollment link — without an administrator having to issue a binding job. Registered keys can be removed from the same place. |
| Security Keys Shown with Their Make and Model | FIDO2 credentials appear alongside your other passkeys in both the end-user console and the Admin Console, labeled with the make and model of the security key that created them, so a user with several keys can tell them apart. Passkey tabs have been renamed so the distinction between passkey types is obvious at a glance. |
| FIDO2 Details Available to Authentication Policy | Policy can be written against the key used to authenticate: its make and model (AAGUID), whether it is a built-in or a portable key, and whether the user was verified by PIN or biometric. FIDO2 authentications also report the same device information as other sign-in methods, so device signals reach policy and appear in event history. |
| Attestation Validated to a FIDO Root of Trust | FIDO2 attestation statements are verified against the FIDO Alliance Metadata Service, so a key’s claim about what hardware it is can be traced to a trusted root rather than accepted at face value. Keys presenting the older FIDO-U2F attestation format are supported as well. The service also verifies the origin, ceremony type, and relying-party identity carried in every WebAuthn assertion, and rejects key-bearing assertions that arrive without a signature. |
| Fewer Prompts During Sign-In | When a sign-in identifies the user up front, the service tells the browser exactly which credential to use, so hardware keys no longer present an unnecessary account chooser and honor the configured user-verification setting instead of always prompting for a PIN. When a FIDO2 security key is the only way for a user to recover access, the ceremony starts on its own rather than waiting for an extra click. |
| Branded, Actionable Error Messages | Errors raised during a FIDO2 sign-in are translated into human-readable messages carrying your tenant’s logo and support contact, and a policy denial shows the custom message the administrator configured rather than a generic failure. |
| Accessibility | The end-user FIDO2 sign-in and enrollment screens meet WCAG 2.1 AA, including keyboard navigation, focus indicators, and screen-reader labeling. |
Bug Fixes
| Bug Fix | Description |
|---|---|
| Deleting a Suspended Passkey | Resolved an issue where attempting to delete a suspended passkey returned a generic failure instead of explaining why the passkey cannot be removed. |
| Passkey Enrollment Email | Resolved an issue where sending a passkey enrollment email failed for tenants that do not have an Admin Console application configured. FIDO2 is now also a selectable passkey type on the email enrollment path. |
| Passkey Events Record the Acting User | Resolved an issue where passkey deletions performed from the end-user console were recorded against an anonymous actor rather than the signed-in user, and where passkey-added events were missing their outcome. |
Comments
0 comments
Please sign in to leave a comment.