IA-5 Identification and Authentication

Authenticator Management

High Risk Moderate Medium Cost

IA-5 requires managing information system authenticators by verifying identity before enrollment, establishing initial authenticator content, ensuring adequate strength, establishing refresh/loss/compromise procedures, protecting authenticator feedback, and changing default authenticators. Passwords, MFA devices, certificates, passkeys, and API keys that protect ePHI all fall here.

Control Objective

Keep authenticators strong, secret, and lifecycle-managed so stolen or default credentials cannot silently unlock systems with ePHI.

Implementation Guidance

  1. Ban default vendor passwords on EHR appliances, biomed devices, and network gear on day one.
  2. Enforce password length/complexity or better — prefer long passphrases and password managers; screen against breached-password lists where feasible.
  3. Issue MFA authenticators only after identity proofing; maintain recovery codes under controlled process.
  4. Protect authenticators at rest (hashed passwords, HSM/KMS for keys) and in use (no cleartext display, masked entry).
  5. Define lost/stolen token and compromise reset procedures with identity verification (watch for social engineering).
  6. Rotate secrets for service accounts and API keys on a schedule and on personnel change.
  7. Prefer phishing-resistant authenticators for privileged users.
  8. Never store production passwords in tickets, chat, or shared spreadsheets.

Real-World Use Cases

How this control shows up in healthcare and HIPAA-covered environments.

Imaging device still on factory password

A PACS modality admin account used the vendor default. Attackers scanned it from a mis-segmented VLAN. IA-5 onboarding checklist forces password change and inventory of device authenticators before go-live.

MFA fatigue on a privileged account

An admin approves endless push prompts and gets phished. IA-5 + IA-2 move admins to number-matching or FIDO2 keys and train on prompt bombing.

API key in a Git repo

A developer commits an interface engine API key. Secret scanning + IA-5 rotation procedures revoke and re-issue the key, and block future commits of secrets.

Best Practices

  • Change all defaults before production use.
  • Use a password manager / vault for teams.
  • Rotate and vault service secrets; no long-lived embedded passwords.
  • Protect MFA recovery paths as carefully as primary auth.
  • Hash and salt human passwords with modern algorithms.
  • Test authenticator reset help-desk scripts against social engineering.

Common Gaps & Violations

  • Default biomed and appliance passwords unchanged.
  • Passwords shared in Teams/Slack for 'coverage.'
  • MFA bypass list with no expiry.
  • Password hints that reveal authenticator content.
  • Certificates and API keys never rotated after contractor departure.

Required Documentation

  • Authenticator management standard (passwords, MFA, certs, keys)
  • Initial authenticator issuance / identity proofing procedure
  • Lost/compromise reset runbooks
  • Service account / API key vault inventory
  • Evidence defaults are changed on new systems

How to Test & Validate

  1. Sample new devices/apps for default credential presence.
  2. Attempt password reset via help desk using weak identity proofing; confirm stronger verification is required.
  3. Verify MFA enrollment requires identity checks.
  4. Confirm service secrets are in a vault and not in plain config files.
  5. Review MFA bypass exceptions for expiry dates.

Audit Considerations

Expect questions about default passwords on clinical devices and how MFA resets are verified. Authenticator weaknesses often appear in penetration test reports — map remediations to IA-5.

HIPAA Mapping

How this NIST control supports HIPAA Security Rule expectations.

  • 164.308(a)(5)(ii)(D) Password Management — procedures for creating, changing, and safeguarding passwords.
  • 164.312(d) Person or Entity Authentication — authenticators implement this specification.
  • 164.312(a)(2)(iv) Encryption and Decryption — cryptographic keys used as authenticators need lifecycle care.
  • 164.308(a)(1) Risk Analysis — weak/default authenticators are recurring risk findings.

Compliance Tips

  • Add 'defaults changed' to every biomed and appliance go-live checklist.
  • Move team-shared passwords into a vault with logging — then eliminate them where possible.
  • Align password length guidance with current NIST SP 800-63B thinking (favor length over frequent forced rotation without cause).

Frequently Asked Questions

Should we force password changes every 60 days?

Modern NIST guidance favors long passwords, breach detection, and change-on-compromise over arbitrary frequent rotation. Document your approach in policy.

Are MFA push notifications enough for admins?

Push can be phished via fatigue. Prefer phishing-resistant authenticators for privileged ePHI administration.

Do API keys count as authenticators under IA-5?

Yes. Manage issuance, storage, rotation, and revocation like other authenticators.

References & Resources

  • NIST SP 800-53 Rev. 5 — IA-5
  • NIST SP 800-63B
  • HIPAA §§ 164.308(a)(5), 164.312(d)
  • Related controls: IA-2, IA-4, AC-7, SC-12, SC-13

Need Help Implementing IA-5?

Our auditors map NIST SP 800-53 controls to your HIPAA Security Rule program — policies, technical evidence, and audit readiness.