| Unauthorized key use or loss of control |
Some syncable authenticator deployments support sharing authentication keys to devices that belong to other users who can then misuse the key. |
Enforce enterprise device management features or managed profiles that prevent synced keys from being shared. |
| |
|
Provide mechanisms for users to view keys, key statuses, and whether/where keys have been shared. |
| |
|
Educate users about the risks of unauthorized key use through existing awareness and training mechanisms. |
| Sync fabric compromise |
To support key syncing, most implementations clone keys to a sync fabric (i.e., a cloud-based service connected to multiple devices associated with an account). |
Store only encrypted key material. |
| |
|
Implement sync fabric access controls that prevent anyone other than the authenticated user from accessing the authentication key. |
| |
|
Evaluate cloud services for baseline security features (e.g., FISMA moderate protections or comparable). |
| |
|
Leverage hardware security modules to protect encrypted keys. |
| Unauthorized access to sync fabric and recovery |
Synced keys are accessible via cloud-based account recovery processes, which represent a potential weakness to the authenticators. |
Implement authentication recovery processes that are consistent with SP 800-63B. |
| |
|
Restrict recovery capabilities for federal enterprise keys through device management or managed account capabilities. |
| |
|
Bind multiple authenticators at AAL2 and above to support recovery. |
| |
|
Require AAL2 authentication to add any new authenticators for user access to the sync fabric. |
| |
|
Only use synced keys as a derived authenticator in federal enterprise scenarios [SP800-157]. |
| |
|
Notify the user of any recovery activities. |
| |
|
Leverage a user-controlled secret (i.e., something not known to the sync fabric provider) to encrypt and recover keys. |
| Revocation |
Since syncable authenticators use RP-specific keys, the ability to centrally revoke access based on those keys is challenging. For example, with traditional PKI, CRLs can be used centrally to revoke access. A similar process is not available for syncable authenticators or any FIDO WebAuthn-based credentials. |
Implement a central identity management (IDM) account for users to manage authenticators and remove them from the “home agency” account if they are compromised or expired. |
| |
|
Leverage SSO and federation to limit the number of RP-specific keys that will need to be revoked in an incident. |
| |
|
Establish policies and tools to request that users periodically review keys for validity and currency. |