IA-7 Cryptographic Module Authentication requires mechanisms for authenticating to a cryptographic module that meet the requirements of applicable laws, directives, policies, regulations and standards. In other words: whoever operates the thing that holds your keys must prove who they are, to the standard that applies to you.
800-53 binds US federal systems and contract holders. Others can use it as a reference when asked who can touch the key store.
What it means in practice
NIST explains that a module may need to authenticate an operator and verify the operator is allowed to assume the requested role and perform services within it. Hardware security modules, cloud key management services and smart cards are typical examples. The standard that sets the details is usually FIPS 140 validation requirements, which you should confirm for your own case.
Evidence to collect
- A list of cryptographic modules and key services in use.
- Roles defined for each, such as crypto officer and user, with the people assigned.
- Authentication settings, such as MFA for the cloud key service console or PINs and quorum for an HSM.
- Access logs for administrative operations.
Common gaps
Shared admin access to a key service. Roles never reviewed. No log of who exported or rotated a key.
How to implement it
Give each operator a named identity, require MFA, split roles and review membership quarterly.
Quick check
What does IA-7 check besides identity?
That the operator is authorized for the role they are assuming and the services within that role.
