Block raw SQL to EHR database
Analysts lose direct production SQL that bypassed app authorization; reporting moves to mediated views.
Reference Monitor
High Risk
Complex
High Cost
AC-25 implements a reference monitor that mediates access attempts, is tamper-resistant, and is small enough to analyze and test. Commercial EHRs rarely expose a classical security kernel, but healthcare organizations still apply the intent: non-bypassable authorization on APIs and databases, protected policy stores, and testable enforcement modules for ePHI.
Control Objective
Ensure critical ePHI access mediation is non-bypassable, protected from tampering, and verifiable through analysis and testing.
Implementation Guidance
- Identify enforcement modules that must not be bypassed (API authz, DB row filters, EHR security services).
- Remove direct DB access paths that skip application authorization for production ePHI.
- Protect policy and config stores that drive enforcement.
- Prefer privileged access via PAM; no standing ability to disable enforcement quietly.
- Include authorization bypass tests in release QA.
- Monitor attempts to disable security modules or open wide grants.
- Document residual bypass risks (vendor tools, break-glass).
- For custom apps, keep authorization modules modular and reviewable.
Real-World Use Cases
How this control shows up in healthcare and HIPAA-covered environments.
API must call authz service
Microservice PRs fail CI if ePHI routes do not invoke the shared authorization library.
Tamper attempt on policy store
A change to security policy outside CAB triggers an alert; enforcement config is integrity-monitored.
Best Practices
- Eliminate bypass paths to ePHI data stores.
- Protect policy integrity.
- Test non-bypassability in QA.
- Monitor disablement of security features.
- Minimize privileged standing access.
- Document vendor limitations honestly.
Common Gaps & Violations
- DBAs with unlogged production SELECT.
- Feature flags that disable authorization in production.
- Unreviewed custom reports hitting base tables.
- Claiming AC-25 while shares can bypass.
- No tests for authorization bypass.
Required Documentation
- Reference monitor / enforcement integrity standard (AC-25)
- Bypass path inventory and closures
- Policy store protection evidence
- QA bypass test results
- Residual risk acceptances
How to Test & Validate
- Attempt direct data-path bypass in test—expect fail.
- Verify integrity monitoring on policy stores.
- Review privileged DB grants.
- Confirm CI checks for authz library use.
- Inspect break-glass bypass logging.
Audit Considerations
AC-25 is advanced; assessors accept risk-based application of the intent on commercial EHRs if bypasses are controlled and documented.
HIPAA Mapping
How this NIST control supports HIPAA Security Rule expectations.
- 164.312(a) Access Control — technical enforcement must be effective, not optional.
- 164.312(c) Integrity — protect security mechanisms from unauthorized change.
- 164.308(a)(1) Risk Management — bypass paths are critical residual risks.
- 164.312(b) Audit Controls — mediation events should be examinable.
Compliance Tips
- Be honest about COTS EHR limits in the SSP.
- Prioritize closing direct DB and flat-file bypasses.
- Put authz bypass tests in every major release.
Frequently Asked Questions
Must we build a formal security kernel?
Not typically for COTS EHR; apply non-bypassable, tamper-resistant, testable mediation as far as architecture allows.
Is AC-25 in every baseline?
Confirm your overlay; implement intent where ePHI bypass risk is high.
Relation to AC-3?
AC-3 requires enforcement; AC-25 strengthens integrity and non-bypassability of the enforcement mechanism.
References & Resources
- NIST SP 800-53 Rev. 5 — AC-25
- Related controls: AC-3, AC-24, SI-6, SI-7, CM-5
Related Guidelines
Related controls that commonly accompany AC-25.
Need Help Implementing AC-25?
Our auditors map NIST SP 800-53 controls to your HIPAA Security Rule program — policies, technical evidence, and audit readiness.