RC4 Kerberos Can Create a Compliance Finding

Many organizations treated RC4 Kerberos hardening as a Microsoft deadline problem. Compliance is a separate question. Depending on your framework, active RC4 usage in Active Directory can create a compliance finding, whatever date Microsoft chose for its changes.

Microsoft’s timeline set when behavior changed. Compliance obligations follow their own schedule. For CISOs and compliance officers in regulated industries, the question was whether RC4 could be an audit issue and what that meant for the next audit.

The answer depends on the framework, the scope of the audit, and how your organization uses Kerberos. For some regulated organizations, unmitigated RC4 in Active Directory can create a finding.

Why RC4 Can Matter Under Several Frameworks

Microsoft’s documentation describes RC4 as insecure. In Kerberos, RC4-encrypted service tickets are Kerberoastable: an attacker who captures an RC4 service ticket can try to crack the account password offline. MITRE ATT&CK documents this as a technique.

The frameworks below generally require strong or appropriate cryptography. They do not name RC4 in Kerberos. NIST SP 800-131A Revision 2 (March 2019), which sets out the approval status of cryptographic algorithms and key lengths, does not name RC4. Revision 3 was still a draft when this post was updated. How an assessor reads RC4 under a given control depends on the framework, the control wording, and the assessor.

HIPAA: Health Insurance Portability and Accountability Act

HIPAA’s Security Rule does not prescribe specific encryption algorithms. It lists “encryption and decryption” as an addressable implementation specification under the Technical Safeguards standard (45 CFR § 164.312(a)(2)(iv) and § 164.312(e)(2)(ii)).

HHS also proposed Security Rule updates that would make encryption required rather than addressable. As of October 4, 2026, we could not confirm that HHS has issued a final rule. Check HHS for the current status.

Healthcare: If your Active Directory environment uses RC4 for Kerberos authentication of systems that access, store, or transmit electronic protected health information (ePHI), whether that is adequate protection is a fair question in a HIPAA risk analysis or audit. Microsoft describes RC4 as insecure, so an assessor may ask about it.

RC4 usage can be a documentable gap. The appropriate response is remediation with documented evidence, or a documented reason for any remaining dependency.

PCI DSS: Payment Card Industry Data Security Standard

PCI DSS v4.0.1 requires strong cryptography in several places. Requirement 4.2.1 covers cardholder data in transit over open, public networks, so it reaches internal Kerberos traffic only in limited cases. Requirement 8.3 covers strong authentication for system access, and whether it reaches Kerberos tickets depends on the scope of your cardholder data environment and on how your assessor reads it.

PCI DSS v4.0.1 requirement 12.3.3 also addresses cryptographic cipher suites and protocols: it calls for an inventory of those in use, a review at least once every 12 months, and a documented approach to cryptographic weaknesses.

Card data: Any organization with card data in scope can be affected, not only financial services and retail. If RC4 is active in the Kerberos traffic of systems in PCI scope and you have not inventoried it, that can be a gap against requirement 12.3.3. If you have inventoried it and identified RC4 as weak, and you do not have a documented remediation plan, that can be a finding. If cardholder data systems are domain-joined and authenticating through RC4, requirement 8.3 may also be in play.

A Qualified Security Assessor (QSA) may ask about Kerberos encryption posture. Documented evidence of AES key validation is a stronger answer than “we are working on it.”

SOC 2: Service Organization Control 2

SOC 2 Trust Services Criteria do not mandate specific encryption algorithms. They require controls sufficient to meet the applicable criteria. The summaries below are ours. Read the full wording in the AICPA Trust Services Criteria.

CC6.1 (logical access security): This criterion covers logical access security software, infrastructure, and architectures that protect information assets. The use of a known-weak encryption algorithm for authentication is relevant.

CC6.7 (transmission of information): This criterion covers restricting the transmission, movement, and removal of information and protecting it while it is transmitted. Kerberos authentication sends tickets, and an auditor could treat RC4 use for that exchange, when AES is available, as a control deficiency.

SaaS and technology companies: SOC 2 auditors apply professional judgment. In a Type II audit covering a period when RC4 was active in Kerberos, with no compensating control or documented remediation plan, an auditor may note it. A period that includes dates after April 14, 2026, when Microsoft changed the default behavior, may draw more attention to RC4.

NIST 800-53: Federal and FedRAMP Environments

NIST SP 800-53 Revision 5 includes control SC-13 (Cryptographic Protection), which addresses the cryptography an organization uses for each cryptographic purpose. The control does not name RC4.

FedRAMP organizations: Annual assessments and continuous monitoring can include Active Directory configuration checks. An assessor may raise active RC4 in Kerberos under SC-13 or related controls. Treat it as an item to remediate or to document, with evidence.

CMMC: Cybersecurity Maturity Model Certification

CMMC Level 2 requirements map to NIST SP 800-171. In the Revision 2 numbering (Revision 2 was superseded by Revision 3 in May 2024, so check which revision your assessor uses), requirement 3.13.8 calls for cryptographic mechanisms to prevent unauthorized disclosure of controlled unclassified information (CUI) during transmission, and requirement 3.13.10 calls for establishing and managing cryptographic keys.

Defense contractors: Whether RC4 in Kerberos is a gap against these requirements depends on your system security plan scope and on the assessor’s reading. If you handle CUI on domain-joined systems, expect the question and keep documentation ready.

The Common Thread

Each framework asks a version of the same question through different language:

• HIPAA: whether authentication for ePHI systems is adequately protected.
• PCI DSS: whether the organization has inventoried and addressed a weak cipher (requirement 12.3.3).
• SOC 2: whether there is a control deficiency in logical access security (CC6.1, CC6.7).
• NIST 800-53 and FedRAMP: whether cryptographic protection (SC-13) holds up.
• CMMC: whether the system meets the cryptographic protection requirements (3.13.8, 3.13.10).

The question is whether RC4 is in use within your audit scope.

What “Documented Evidence” Means for Auditors

An auditor will want evidence that you:

1. Assessed your environment and identified all RC4 usage
2. Confirmed from KDC event evidence which accounts have AES key material, meaning the keys are present in the KDC and not only that attributes are set
3. Set a dated, sequenced remediation plan, or documented a reason for any remaining dependency
4. Carried out the plan and kept documented proof

A dated record with per-account AES key confirmation can help answer an assessor’s questions. Where legacy systems prevented full enforcement, the record should also say which dependency remains, why, and what controls surround it.

Sources

• NIST SP 800-131A Revision 2: Transitioning the Use of Cryptographic Algorithms and Key Lengths
• NIST SP 800-53 Revision 5: Security and Privacy Controls
• NIST SP 800-171 Revision 2: Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
• NIST SP 800-171 Revision 3: Protecting Controlled Unclassified Information
• 45 CFR § 164.312 (HIPAA Technical Safeguards)
• HHS HIPAA Security Rule NPRM
• PCI DSS v4.0.1 Document Library (PCI Security Standards Council)
• CMMC Program (DoD CIO)
• Microsoft Learn: Detect and Remediate RC4 Usage in Kerberos
• Microsoft: Managing Kerberos KDC usage of RC4 (CVE-2026-20833)
• MITRE ATT&CK T1558.003 Kerberoasting