Impossible travel to EHR
User authenticated in Ohio then attempts EHR from overseas minutes later; IA-10 adaptive policy demands step-up and SOC review.
Adaptive Authentication
High Risk
Moderate
Medium Cost
IA-10 requires individuals and/or devices to satisfy additional authentication requirements based on organization-defined circumstances or risk indicators. Healthcare IdPs can step up MFA, block, or challenge when clinicians or admins attempt EHR access from new countries, jailbroken devices, or impossible travel patterns.
Control Objective
Apply additional authentication or blocking when defined risk circumstances are detected for users/devices accessing ePHI systems.
Implementation Guidance
- Define risk signals: new geo, new device, TOR/VPN anomalies, impossible travel, privileged role elevation.
- Configure IdP adaptive policies for EHR, VPN, email, and admin consoles.
- Prefer step-up MFA over silent allow for medium risk; block for high risk.
- Tune to reduce unsafe clinical lockouts—involve informatics.
- Log adaptive decisions for AU review.
- Cover contractors and BA users in scope when federated.
- Test break-glass path that still authenticates strongly.
- Review false positives monthly.
Real-World Use Cases
How this control shows up in healthcare and HIPAA-covered environments.
New device for coding VPN
Coder’s first login from unknown laptop requires device registration plus MFA before VDI with ePHI opens.
Privileged role activation
Requesting domain admin triggers additional authentication and PAM checkout beyond standard network login.
Best Practices
- Risk-based signals tied to ePHI apps.
- Step-up rather than permanent friction for clinicians.
- Log adaptive outcomes.
- Include federated BAs.
- Tune with clinical IT.
- Keep strong break-glass.
Common Gaps & Violations
- Adaptive rules only on email, not EHR.
- Permanent allow-lists that neuter policy.
- No tuning—mass lockouts create workarounds.
- Ignoring device posture signals.
- No logging of step-up failures.
Required Documentation
- Adaptive authentication standard (IA-10)
- Risk signal definitions
- IdP policy screenshots/config
- Tuning/exception process
- Sample adaptive event logs
How to Test & Validate
- Simulate new-geo access in test—expect step-up/block.
- Verify EHR/VPN covered by policy.
- Review false-positive tickets for 30 days.
- Confirm privileged elevation requires extra auth.
- Test break-glass still strongly authenticated.
Audit Considerations
IA-10 evidence is conditional authentication policies—not static MFA alone.
HIPAA Mapping
How this NIST control supports HIPAA Security Rule expectations.
- 164.312(d) Person or Entity Authentication — strengthen authentication under risk.
- 164.312(a) Access Control — limit access under anomalous conditions.
- 164.308(a)(1) Risk Management — adaptive controls reduce account-takeover residual risk.
- 164.312(b) Audit Controls — record adaptive decisions.
Compliance Tips
- Prioritize EHR, VPN, and admin consoles for adaptive policies.
- Align with zero-trust conditional access.
- Report adaptive blocks as security metrics.
Frequently Asked Questions
Is IA-10 required if we already have MFA?
MFA is baseline; IA-10 adds circumstance-based additional requirements.
Will this harm ED clinicians?
Tune carefully—use device compliance and role-aware policies; avoid crude geo blocks on roaming specialists without alternatives.
Related to IA-2?
IA-2 covers authenticator types; IA-10 adapts requirements based on risk circumstances.
References & Resources
- NIST SP 800-53 Rev. 5 — IA-10
- Related controls: IA-2, IA-11, AC-2, SI-4
Related Guidelines
Related controls that commonly accompany IA-10.
Need Help Implementing IA-10?
Our auditors map NIST SP 800-53 controls to your HIPAA Security Rule program — policies, technical evidence, and audit readiness.