Cyber insurance renewals have gotten harder to navigate since 2021. What used to be a questionnaire checkbox is now a technical control verification with direct consequences for premiums, sub-limits, and claims outcomes. RC4 Kerberos encryption is one of those controls.

If your organization is in a renewal cycle before July 14, 2026, here’s what underwriters are asking, what the claims exposure looks like, and what evidence actually satisfies the requirement.

Why Carriers Started Asking About RC4

RC4 is a legacy encryption algorithm that Microsoft’s Kerberos implementation has used for decades. By modern standards it is cryptographically weak. RC4-based Kerberos tickets can be cracked offline at millions of attempts per second using commodity hardware and freely available tools.

Three of the most common attack patterns in enterprise breaches (Golden Ticket attacks, Kerberoasting, and Pass-the-Ticket) either require RC4 or become significantly easier when RC4 is present in the environment.

Forensic teams engaged during breach investigations routinely find RC4 Kerberos tickets in the attack chain. Carriers noticed. RC4 began appearing in underwriting questionnaires around 2021 and has since moved into technical verification requirements at the larger carriers.

Microsoft’s enforcement timeline made this concrete. The phased deprecation rollout that began with the April 2026 updates concludes on July 14, 2026. Several Lloyd’s syndicates have referenced that date in renewal conditions as a trigger for coverage requirements.

The Claims Exposure Is Real

If a breach investigation finds RC4 Kerberos in the attack chain and your renewal questionnaire said your environment was hardened, you have a coverage problem.

Carriers are increasingly specific about what “hardened” means. Checking a box that says your organization uses strong encryption is not the same as producing timestamped evidence that RC4 was inventoried, affected accounts were remediated, and AES enforcement was verified. The difference between those two positions is where claim disputes are happening.

Some policies now include explicit weak-encryption exclusions. Others carry coverage conditions that require documented remediation before a certain date. If you don’t know which category your policy falls into, your broker should be able to tell you before your next renewal.

What Underwriters Are Actually Asking For

The questionnaire items vary by carrier, but the underlying verification need is consistent. Has the organization identified all accounts, service accounts, and domain controllers that are RC4-dependent? Have affected accounts been remediated to AES? Has KRBTGT been rotated with the double-reset protocol to confirm new AES keys are in use? Is there documented evidence of all of the above, with dates, generated after remediation was completed?

That last point is where most organizations fall short. Saying “we believe we’re compliant” is not the same as a report showing account-by-account remediation status with analyst review and a timestamp. Underwriters are asking for the report because the questionnaire answer alone no longer satisfies technical underwriting standards at carriers that know what they’re looking at.

What This Means Before July 14

You have 54 days. That window covers both the remediation work and the documentation cycle. If you’re in a renewal between now and late summer, the two timelines are overlapping.

Organizations that go into renewal after July 14 without documented evidence of RC4 remediation will have a harder conversation than those who arrive with a clean assessment report. Before July 14, you can still demonstrate active remediation in progress. After it, the question becomes why it wasn’t done.

If you don’t know your current RC4 exposure, start with a scoped assessment that identifies every dependent account and documents your baseline. That report is also what you hand your broker for the renewal file.

PresideTech’s RC4 Detect assessment produces a timestamped, analyst-reviewed report covering every account, domain controller, and domain configuration that underwriters are now asking about. The report includes pre-AES credential exposure, KRBTGT rotation status, service account RC4 dependency, and AES enforcement verification, structured for both your security team and your insurance renewal.

Sources

• Microsoft: Managing Kerberos KDC usage of RC4 (CVE-2026-20833)
• Microsoft TechCommunity: Phase 2 of Kerberos RC4 hardening (April 2026)
• NIST SP 800-131A Revision 2: Transitioning the Use of Cryptographic Algorithms
• MITRE ATT&CK: Steal or Forge Kerberos Tickets (T1558)