Version Affected: 24.04+
Overview
When migrating or upgrading an IdP to a version that newly enforces device permission granularity by AAGUID (Authenticator Attestation Globally Unique Identifier), some existing FIDO2 enrollments can be disabled and require the user to re-enroll.
Cause
As long as the domain name stays the same across an IdP migration or upgrade, users normally do not need to re-enroll their FIDO2 devices. However, some newer IdP versions newly enforce device permission granularity by AAGUID, allowing only specific iCloud Keychain AAGUIDs (managed/standard) and disallowing all-zero AAGUIDs. When this enforcement is newly in effect, every enrollment with an attestation of none is disabled — including enrollments from Apple devices, which report an all-zero AAGUID. Without a non-all-zero AAGUID, the IdP cannot determine which passkey provider the enrollment came from, so it cannot be trusted under the new enforcement.
Resolution:
Users whose existing FIDO2 enrollment is affected by this enforcement will need to re-enroll their device after the migration or upgrade.
Special Considerations
The AAGUID reported to the IdP is determined by the authenticator itself, not by SecureAuth. Apple devices, such as Macs, typically report an all-zero AAGUID (00000000-0000-0000-0000-000000000000), even when the user selects direct attestation. This is because Apple uses Anonymous CA attestation, which is not included in the FIDO Metadata Service (MDS).
SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.
Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.
Comments
0 comments
Please sign in to leave a comment.