SC-20 System and Communications Protection

Secure Name / Address Resolution Service (Authoritative Source)

High Risk Moderate Medium Cost

SC-20 requires that authoritative name/address resolution services provide data origin authentication and integrity verification (commonly via DNSSEC or equivalent trusted resolution controls) so clients can trust answers from organizational authoritative sources. In healthcare, poisoned or rogue authoritative data can silently redirect EHR, VPN, telehealth, and partner interface traffic carrying ePHI.

Control Objective

Protect authoritative DNS (and equivalent name/address services) that publish healthcare zones so resolved names for ePHI systems are authentic and integrity-protected.

Implementation Guidance

  1. Inventory authoritative DNS for clinical, corporate, and partner zones that name ePHI systems.
  2. Enable DNSSEC (or documented equivalent) on authoritative servers; publish DS records to parents.
  3. Restrict zone update privileges; require MFA/PAM for DNS admin; log all changes.
  4. Separate internal authoritative views for EHR/PACS hostnames from public marketing zones where possible.
  5. Monitor zone serial changes and unexpected record modifications (SI-4).
  6. Protect hidden primaries and transfer channels (TSIG/ACL) between authoritative nodes.
  7. Include DNS in change control (CM-3) for clinical go-lives and cutovers.
  8. Test validation failure behavior with recursive resolvers (pairs with SC-21).

Real-World Use Cases

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

EHR cutover CNAME hijack risk

During an Epic/Cerner cutover, only PAM-approved DNS admins can publish the new EHR aliases; SC-20 integrity controls and change tickets prevent an unauthorized CNAME from diverting clinicians to a lookalike host.

Partner interface hostname trust

A clearinghouse SFTP hostname is served from the health system’s authoritative zone with DNSSEC so billing interfaces do not accept silently altered address data.

Telehealth vanity domain

Patient-facing telehealth names remain under signed authoritative control so phishing sites cannot easily ride on unauthorized zone edits from a compromised DNS console.

Best Practices

  • Prefer DNSSEC on authoritative healthcare zones.
  • PAM + MFA for DNS administrators.
  • Alert on unexpected zone changes.
  • Split-horizon carefully; document views.
  • Include DNS in clinical change windows.
  • Pair with SC-21/SC-22 architecture.

Common Gaps & Violations

  • Dynamic updates wide open from clinical VLANs.
  • Shared DNS admin password.
  • No logging of zone modifications.
  • Public and internal clinical names in one flat, weakly protected zone.
  • DNS treated as "network only" outside the SSP.

Required Documentation

  • Authoritative DNS security standard (SC-20)
  • Zone inventory tied to ePHI systems
  • DNSSEC/equivalent configuration evidence
  • DNS admin access and change-control procedures
  • Monitoring use cases for zone changes

How to Test & Validate

  1. Verify DNSSEC signatures (or equivalent) on sample clinical zone records.
  2. Attempt unauthorized dynamic update from a test host — expect deny.
  3. Review DNS admin access list vs PAM.
  4. Confirm zone-change alerts fire in SIEM.
  5. Trace a recent EHR hostname change to an approved ticket.

Audit Considerations

Assessors look for whether name services that steer ePHI traffic are integrity-protected and tightly administered—not only whether \"DNS exists.\"

HIPAA Mapping

How this NIST control supports HIPAA Security Rule expectations.

  • 164.312(e) Transmission Security — integrity of electronic ePHI in transit depends on resolving to the intended endpoint.
  • 164.312(c) Integrity — unauthorized alteration of DNS data undermines system integrity.
  • 164.308(a)(1) Risk Analysis — DNS hijack is a realistic threat to ePHI availability and confidentiality.
  • 164.308(a)(5) Security Awareness — admins need training on DNS change risk.

Compliance Tips

  • List authoritative DNS as a critical ePHI-supporting system in the asset inventory.
  • Put DNS zone changes on the same CAB path as firewall changes for clinical domains.
  • Evidence SC-20 together with SC-21 and SC-22.

Frequently Asked Questions

Is DNSSEC mandatory for SC-20?

NIST emphasizes origin authentication and integrity for authoritative sources; DNSSEC is the common mechanism—document equivalents if used.

Does SC-20 cover recursive resolvers?

SC-20 focuses on authoritative sources; SC-21 addresses recursive/caching resolvers.

Are cloud DNS zones in scope?

Yes, when they publish names for systems that create, receive, maintain, or transmit ePHI.

References & Resources

  • NIST SP 800-53 Rev. 5 — SC-20
  • Related controls: SC-21, SC-22, SC-8, SI-4, CM-3
  • NIST SP 800-81 (Secure DNS)

Need Help Implementing SC-20?

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