SC-23 System and Communications Protection

Session Authenticity

High Risk Moderate Low Cost

SC-23 requires protecting the authenticity of communications sessions. Stolen cookies, missing secure flags, and session fixation against patient portals or EHR web UIs enable account takeover without guessing passwords — directly exposing ePHI.

Control Objective

Ensure sessions that access ePHI are uniquely established, integrity-protected, and invalidated appropriately so attackers cannot hijack or replay authentic sessions.

Implementation Guidance

  1. Require secure, HTTP-only, properly scoped session cookies for web EHR/portals.
  2. Regenerate session IDs at login and privilege change.
  3. Use TLS for all session traffic (SC-9).
  4. Implement logout and idle timeout that invalidate server-side sessions.
  5. Consider binding sessions to device/network risk signals for high-risk apps.
  6. Monitor for session anomalies (impossible travel, concurrent sessions).
  7. Include API tokens/JWT life-cycle and revocation for ePHI APIs.
  8. Test for fixation/hijacking in SA-11 evaluations.

Real-World Use Cases

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

Portal session cookie theft

Secure cookie flags and short idle timeout under SC-23 limit replay from a stolen laptop browser.

Privilege elevation without new session

EHR admin elevation regenerates session ID to prevent fixation.

Stale API token for FHIR app

Token expiry and revocation stop a departed BA integration from reading ePHI.

Best Practices

  • Secure cookie/token settings.
  • Session ID rotation at login.
  • Server-side invalidation on logout/idle.
  • Anomaly monitoring.
  • API token life-cycle.
  • Include in app testing.

Common Gaps & Violations

  • Sessions survive logout.
  • Cookies without Secure/HttpOnly.
  • No idle invalidation server-side.
  • Long-lived API tokens in mobile apps.
  • No testing for session fixation.

Required Documentation

  • Session authenticity standard (SC-23)
  • Web/API session configuration baselines
  • Monitoring use cases
  • Application test evidence
  • Token management procedures

How to Test & Validate

  1. Review cookie/token settings on patient portal/EHR web.
  2. Verify server invalidation on logout/timeout.
  3. Check API token lifetimes for ePHI APIs.
  4. Review anomaly detections.
  5. Sample SA-11 tests covering session management.

Audit Considerations

Session attacks bypass password controls. Assessors and pen testers routinely check cookie flags and logout behavior on healthcare apps.

HIPAA Mapping

How this NIST control supports HIPAA Security Rule expectations.

  • 164.312(a) Access Control — unique user identification and session management protect ePHI access.
  • 164.312(d) Authentication — session authenticity maintains assurance after initial auth.
  • 164.312(e) Transmission Security — sessions must ride protected channels.
  • 164.308(a)(1) Risk Management — session hijack risk requires treatment.

Compliance Tips

  • Add session management checks to every portal release gate.
  • Prefer server-side session stores with explicit revoke.
  • Shorten tokens for BA integrations.

Frequently Asked Questions

Is MFA enough without SC-23?

MFA helps at login; session authenticity protects the post-login channel from hijack/replay.

How related to SC-10/AC-12?

Those terminate sessions/connections; SC-23 ensures the session that exists is authentic and protected.

Do thick clients need SC-23?

Yes — protect client-server session tokens/keys similarly.

References & Resources

  • NIST SP 800-53 Rev. 5 — SC-23
  • Related controls: AC-12, SC-10, IA-2, SC-8, SA-11

Need Help Implementing SC-23?

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