RC4 fails the strong-cryptography requirements of PCI-DSS 4.0, NIST, and FIPS 140-3. It's still in your Kerberos config.
An automatic audit finding hiding in your Active Directory. Rivest Cipher 4 is silently present in most mid-market environments, in Kerberos, legacy TLS, and embedded crypto in third-party software. When modern systems stop tolerating it, the failure mode is silent connection drops, not breach warnings. When auditors enforce PCI-DSS 4.0 with rigor, it is a finding the board, the cyber insurer, and the next acquirer all see.
Who This Is For
Five seats at the table when RC4 surfaces
RC4 is technical on the inside and executive on the outside. Whichever seat receives the question first determines the timeline. These are the five who carry it.
IT & Security Directors
Own the remediation
You're the one who has to find every instance, plan the encryption-type changes, sequence the service-account rotations, and not break the production Kerberos flow doing it. The assessment gives you the inventory and the staged remediation plan, not a one-line "RC4 detected" alert.
CISO / Security Lead
Carries the defensible posture
When the board, the auditor, or the cyber insurer asks "do you have RC4 in your environment, and what are you doing about it," the answer needs to be a documented inventory and a remediation timeline with citations, not "we think we're fine." This produces that document.
Compliance & GRC Leads
Owns the audit response
PCI-DSS 4.0 § 4.2.1 (strong-cryptography requirement), NIST SP 800-52r2 (FIPS-approved cipher suites only, which excludes RC4), and FIPS 140-3 (RC4 not validated as an approved algorithm) each rule out RC4 with their own evidence expectation. The assessment delivers control-by-control citations and audit-ready language, the same artifact your auditor or assessor will eventually request.
CFO / Board / Audit Committee
Sees the regulatory and insurance exposure
RC4 carries quantifiable exposure: audit findings that delay certification, cyber-insurance questions on encryption posture, and operational risk when major vendors deprecate it. The output translates the technical finding into the financial and regulatory picture leadership actually decides on.
General Counsel
Wants documented control posture
If an incident or breach is later litigated, "we had no idea RC4 was in our environment" is a different legal position than "we had a documented inventory and a remediation plan in execution." The assessment produces the artifact that supports the second position.
Three Distinct Risks
RC4 is three problems wearing one name
A single configuration deprecation produces three different failure modes, each on its own timeline. The first one to materialize for your organization determines the kind of mess you're cleaning up.
Operational
Outage Risk
When Microsoft, vendors, or browser TLS stacks stop tolerating RC4, the failure is a silent connection drop. No alert, no graceful degradation, no warning before the outage hits your authentication flow or a core business integration.
Trigger: Windows update removes RC4 etype default · Vendor sunsets TLS 1.0/1.1 · Browser drops RC4 cipher suite
Regulatory
Compliance Exposure
PCI-DSS 4.0 § 4.2.1, NIST SP 800-52r2, and FIPS 140-3 explicitly disallow RC4. Auditors are flagging it. If you're certified and RC4 is present, it's a finding, the only question is when your auditor catches it.
Trigger: Annual PCI-DSS audit · SOC 2 Type II evidence cycle · State-level financial regulator review
Adversarial
Attack Surface
Kerberoasting attacks specifically target RC4-encrypted Kerberos tickets. It's a documented ransomware-precursor technique, the attacker requests a TGS, harvests the RC4-encrypted ticket, and cracks the service account password offline.
Trigger: Initial AD foothold (phish or stolen creds) · Then lateral movement via Kerberoasting
Background
A 1980s cipher in a 2026 environment
Cryptographically broken for over a decade. Formally deprecated. Still running. Here's how it survives.
Where it typically hides
- Active Directory Kerberos Service accounts with RC4 etype set; encryption-type negotiation defaulting to RC4-HMAC.
- Legacy TLS endpoints Internal services and management interfaces with TLS 1.0/1.1 still enabled and RC4 cipher suites.
- Third-party software Vendor software with embedded crypto libraries that fall back to RC4 for "compatibility".
- WEP wireless Increasingly rare but still present in older industrial and guest-network environments.
- Custom application crypto In-house code from the early 2010s or earlier that hard-coded RC4 and never got refactored.
Why it persists
- Backward compatibility Legacy clients that don't support modern ciphers are kept working by leaving RC4 enabled.
- Default settings nobody revisited Initial AD domain configurations from 2008–2014 left RC4 etype enabled and never changed.
- Vendor defaults Third-party software ships with RC4 fallback for compatibility, and nobody disables it on install.
- Configuration drift Over years of operation, intended state diverges from actual state. RC4 hides in the gaps.
- No clear owner "Crypto policy" rarely has a named owner in mid-market IT. It's everybody's problem and nobody's.
A Sample Finding
What the assessment output actually looks like
An anonymized example of a single finding from a real RC4 Readiness™ engagement. Each finding includes evidence, impact, remediation steps, and a regulatory citation.
14 Active Directory service accounts permit RC4-HMAC Kerberos encryption
- Evidence
- Domain controllers DC01–DC03 (acme.corp),
msDS-SupportedEncryptionTypesattribute =0x1C(RC4_HMAC_MD5 + AES128_HMAC_SHA1 + AES256_HMAC_SHA1) on 14 service accounts. Verified viaGet-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes. - Impact
- Kerberoasting attack surface: an authenticated user can request a service ticket and crack the service-account password offline via the RC4 hash. Multiple of the 14 accounts have password policies older than 365 days. Sustained adversary foothold is likely without remediation, and this finding will be flagged in the next compliance audit. Dollar-quantification of risk (ALE) is available under the Program. RC4 Readiness™ delivers the technical finding and remediation path.
- Citation
- NIST SP 800-52r2 §3.3.1, TLS cipher suites permitted for federal use exclude RC4. PCI-DSS 4.0 §4.2.1, strong cryptography required; RC4 not permitted. Microsoft KB 4520411 / KB5021131, Kerberos RC4 etype deprecated; default behavior tightened across recent Windows updates including the Windows Server 2025 release.
- Remediation
- Stage 1 (week 1): Inventory all kerberoastable accounts; rotate service-account passwords to 25+ characters. Stage 2 (week 2): Set
msDS-SupportedEncryptionTypes=0x18(AES128 + AES256 only, no RC4) for non-legacy accounts. Stage 3 (week 3 to 4): Migrate or retire the 3 legacy-dependent accounts. Stage 4: Disable RC4 etype at domain level. - Owner / target
- IT Director · target close Q3
The Assessment
What Preside RC4 Readiness™ delivers
Full RC4 inventory
Every system, configuration, and code path using RC4, across Kerberos, TLS, wireless, and application crypto. Each item categorized by exposure type and remediation complexity.
Compliance gap map
Each finding mapped to PCI-DSS 4.0, NIST SP 800-52r2, and FIPS 140-3 sections. Audit-ready documentation that pre-empts auditor questions and gives you the citation language.
Outage risk prioritization
Which systems will fail first when major vendors drop RC4 support. Ordered by business criticality, dependency chain, and known vendor sunset dates.
Remediation roadmap
Specific configuration changes, vendor escalations, and migration sequences. Estimated effort, business risk, and dependency analysis for each remediation track.
Delivery Options
Three ways to engage
Self-Service
A short set of questions to help you gauge how exposed your environment is to the RC4 deprecation, and whether the full RC4 Readiness™ assessment is worth scheduling. A few minutes; no commitment.
Take the Self-Assessment →Direct from Preside
Preside delivers the full assessment under our brand. Reports prepared by Preside. Right for organizations that want a direct relationship with the methodology owner and don't already have an advisor relationship in this space.
Direct Engagement →Through a Partner
Co-branded delivery via a Preside partner already advising your organization. Reports read: Prepared by [Partner] · Powered by Preside RC4 Readiness™. Same methodology, continuity with your existing advisor.
Partner Program →Find your RC4 exposure before your auditor does.
A complete inventory and a defensible remediation map, in a few weeks.