HSM admin uses a shared PIN
Two network engineers share the HSM ped PIN on a sticky note. IA-7 requires named operator creds and dual control for key export roles protecting EHR TDE master keys.
Cryptographic Module Authentication
High Risk
Complex
Medium Cost
IA-7 requires implementing mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, executive orders, directives, policies, regulations, standards, and guidelines for authentication to such modules. When HSMs, TPMs, smart cards, or software crypto modules guard ePHI keys, weak module login (shared PIN, no operator auth) collapses the encryption control story.
Control Objective
Authenticate operators and processes to cryptographic modules that protect ePHI keys/operations using approved, appropriately strong mechanisms — not shared or bypassable module access.
Implementation Guidance
- Inventory cryptographic modules in use for ePHI: HSMs, KMS, TPMs, smart cards, disk encryption modules, VPN crypto engines.
- Identify required authentication strength per module role (key custodian vs automated service).
- Enforce individual operator authentication to HSMs/KMS consoles; ban shared root PINs.
- Use MFA or multi-party control for sensitive key ceremonies where required by policy.
- Prefer FIPS-validated modules where your compliance program mandates them; document module cert levels.
- Bind service accounts to least-privilege module APIs with rotated credentials/certs.
- Log authentication successes/failures to modules; alert on anomalies.
- Align IA-7 with SC-12 key custody and IA-2/IA-5 organizational authenticator management.
Real-World Use Cases
How this control shows up in healthcare and HIPAA-covered environments.
Full-disk encryption on clinic laptops
BitLocker/TPM unlock policies define PIN/password strength and recovery key custody so module authentication is not a blank recovery key in the image share.
Cloud KMS API keys in a public repo
A service principal secret for CMEK operations leaks. IA-7/SC-12 response rotates credentials, enforces workload identity, and reviews module auth logs.
Best Practices
- Named operator auth to key modules.
- Dual control for high-impact key ops.
- FIPS-validated modules when required.
- No shared PINs/passwords.
- Logged module authentication events.
- Service identities over long-lived shared secrets.
Common Gaps & Violations
- Shared HSM credentials.
- Crypto “admin” via unauthenticated local console.
- Recovery keys stored with encrypted devices.
- Ignoring module validation requirements in policy.
- No logging of KMS/HSM administrator logins.
Required Documentation
- Cryptographic module authentication standard (IA-7)
- Inventory of modules protecting ePHI
- Operator authentication and dual-control procedures
- FIPS/validation references where applicable
- Module auth logging and review evidence
How to Test & Validate
- Sample HSM/KMS admin access for individual authentication.
- Confirm dual control for a sensitive key ceremony or export.
- Review module auth logs for a recent period.
- Verify laptop crypto unlock/recovery key handling sample.
- Check service access to KMS uses non-shared, rotated credentials.
Audit Considerations
Encryption claims fail audits when module authentication is weak. Expect questions about who can unlock keys and whether FIPS/module requirements in policy are evidenced.
HIPAA Mapping
How this NIST control supports HIPAA Security Rule expectations.
- 164.312(a)(2)(iv) Encryption and Decryption — person/entity authentication to crypto mechanisms supports controlled decrypt capability.
- 164.312(d) Person or Entity Authentication — verify identity of persons seeking access; includes access to cryptographic controls.
- 164.312(e) Transmission Security — crypto modules used for transmission need authenticated administration.
- 164.308(a)(4) Information Access Management — least privilege applies to key-management roles.
Compliance Tips
- Add HSM/KMS admins to privileged access review (AC-2/IA-12).
- Test break-glass module access during contingency exercises without bypassing auth logging.
- Document where FIPS validation is required vs risk-accepted alternatives.
Frequently Asked Questions
Does IA-7 apply if we only use cloud-managed encryption?
Yes for authentication to the cryptographic services/APIs and consoles your staff use — define how admins and workloads authenticate to those modules/services.
Is a password to the EHR the same as IA-7?
No. IA-7 is specifically authentication to cryptographic modules; EHR user auth is primarily IA-2 and related controls.
Are software keystores in scope?
Yes when they function as cryptographic modules protecting ePHI keys — harden authentication to those keystores accordingly.
References & Resources
- NIST SP 800-53 Rev. 5 — IA-7
- FIPS 140 series module guidance
- Related controls: SC-12, SC-13, IA-2, IA-5, AC-3
Related Guidelines
Related controls that commonly accompany IA-7.
Need Help Implementing IA-7?
Our auditors map NIST SP 800-53 controls to your HIPAA Security Rule program — policies, technical evidence, and audit readiness.