Secret Server Cloud - Issues with FIDO2 two-factor mechanism

Incident Overview

On June 3, 2025, customers using FIDO2 two-factor authentication to access Secret Server Cloud experienced a login failure. The typical login flow involved:

1. Launching the Secret Server application
2. Selecting FIDO2 as the authentication method
3. Entering FIDO2 credentials
4. Being redirected back to the login page
5. Repeating the loop without successfully logging in

This issue affected customers using FIDO2 security keys as their second factor in any federated or embedded authentication flow, regardless of identity provider. The login failure occurred without displaying an error to the user, making the problem harder to detect initially.

Users not relying on FIDO2 - such as those using TOTP, mobile authenticators, or password-based authentication - were not affected.

A rollback was initiated and completed across all regions by 7:10 PM ET, restoring login functionality. Some users also regained access by temporarily removing FIDO2 from their accounts.

• Start Time: June 3, 2025, 6:00 PM ET
• End Time: June 3, 2025, 7:10 PM ET

Root Cause

The incident was triggered by a change to the Permissions-Policy HTTP header during a recent deployment. Specifically, the directive interest-cohort=(), originally included to opt out of Google’s deprecated FLoC feature was removed.

While the Permissions-Policy header itself remained present, it did not include explicit permission for required features, most importantly publickey-credentials-get, which governs browser access to WebAuthn APIs used by FIDO2 security keys.

Secret Server Cloud’s login experience utilizes iframes to render authentication panels. Modern browsers such as Chrome enforce stricter default restrictions for iframe-embedded content, requiring explicit delegation in the Permissions-Policy header to allow WebAuthn in cross-origin or nested iframes.

Because the publickey-credentials-get feature was not delegated via the Permissions-Policy header:

• The browser blocked the FIDO2 authentication request inside the iframe.
• The application did not handle this failure visibly and instead redirected users back to the login page, creating a looping login experience for users attempting to authenticate with FIDO2.

Preventive Actions

• Define and enforce a comprehensive Permissions-Policy header that explicitly enables required APIs like publickey-credentials-get, especially in embedded iframe contexts.
• Expand test automation to include FIDO2-based authentication flows across different browser environments and embedded login contexts.

We sincerely apologize for the disruption and are committed to continuing to strengthen the reliability of our platform.