Chapter #4 - RC4, heading toward sunset?
Too good to remain secret, too useful to disappear at once
Versione italiana disponibile qui → [IT]
1987. The world still thought in blocs, borders and enclosures. The clearest example was the Cold War between the United States and the Soviet Union.
Berlin was its most visible symbol, and the Wall was still standing there to remind everyone of it. On June 12 of that year, the then President of the United States, Ronald Reagan, stood in front of the Brandenburg Gate and spoke a sentence that would remain in history as both a provocation and a hope:
“Mr. Gorbachev, tear down this wall!”
A few months later, on December 8, the United States and the Soviet Union signed the INF Treaty, the first concrete sign of a balance that was slowly beginning to crack. Outside, the walls were still there, but somewhere people had already started talking about the future.
It was in that strange suspension, between walls still intact and cracks already visible, that an encryption algorithm destined to last for a very long time was born: RC4.
Not as an open standard, not as a common good, but as an industrial secret. In that same year, Ron Rivest, one of the founders of RSA Data Security, designed the algorithm as part of RSA’s proprietary cryptographic library.
The acronym is commonly expanded as “Rivest Cipher 4”, although according to Ron Rivest himself, the letters RC stood for “Ron’s Code”.
When I think about that 1987, though, I cannot hear only geopolitics or the tension of the Cold War. I hear something else too.
In the clubs, House music was living its golden age, and I was completely fascinated by it, taking my first steps among vinyl records, mixers and a pair of faithful Technics SL-1210 MK2 turntables. The curious thing is that, just like RC4, the musical technology of that time had been built to last. Even today I can switch on the same system and play the same records without any problem.
But speaking of vinyl, if I had to choose one record to frame that historical moment, the first one that comes to mind is Promised Land by Joe Smooth. Because while the world outside was still made of separations, inside that sound there was already the opposite idea:
“brothers and sisters, one day we will be free”
no more division, no more conflict, but the idea that one day we might finally walk in the same direction.
Then November 9, 1989, arrived, and the Berlin Wall really fell. What came down with it was not only a concrete barrier, but the very idea that some fences were natural, inevitable or meant to last forever. From that moment on, the change was not only political. It was cultural. It changed the way people looked at borders, at the circulation of ideas, at the assumption that some things should remain closed forever, creating a domino effect that spread everywhere in the following years.
Five years later, in 1994, that world had not completely ended yet, but it had already lost its original rigidity. And, in a very Nineties kind of way, RC4 also escaped its enclosure through a leak that gained significant public attention: a description of the algorithm was anonymously posted to the cypherpunks mailing list and then reposted on sci.crypt. The secret stopped being a secret and began to circulate.
The story even appeared in TIME with an article titled “The Secret’s Out”. A sign that the leak was no longer only a matter for specialists.
But instead of marking its end, that leak opened a second life for RC4: from an industrial secret it became something that could be shared, implemented and discussed more and more widely.
Another five years passed and, in 1999, Microsoft also decided to adopt RC4 as the standard encryption algorithm for its Kerberos implementation, using it as a compatibility bridge to accompany the transition from existing Windows NT environments and helping it become one of the pillars of Windows authentication for decades to come.
The curious thing is that even then the story was not really considered complete. It would take until December 2006 for this part of its life to be formalized in an RFC, number 4757, documenting the RC4-HMAC encryption types used by Microsoft in Windows.
More than ten years after its public disclosure, almost twenty years after its birth. As if bureaucracy, once again, were simply recording something that practice had already accepted long before.
And right there, between a secret too good to remain hidden and an idea too useful to disappear at once, the story of its decline truly begins.
Why RC4 has really reached sunset
Before explaining why RC4 has reached sunset, it is worth remembering why it was so successful in the first place. It did not spread by chance, nor simply because it was available. For the world of the Nineties, it was almost perfect: fast, simple to implement, light for the hardware of the time and flexible enough to fit into very different contexts. It did not require particularly complex structures, worked well in software and could be adopted in protocols that needed to encrypt data streams in a practical way, without making systems and applications too heavy.
That is why it ended up almost everywhere: in the early versions of SSL and TLS, in Wi-Fi networks with WEP, then WPA and TKIP, and finally, as we have already seen, inside Kerberos in Windows environments. In other words, RC4 was not just an algorithm: it was a practical answer to a very concrete problem, bringing some encryption into a world that was becoming more and more connected, but still could not afford to change everything at once.
So what is really bringing it to an end?
RC4 is not leaving the stage because someone suddenly decided it was simply “old”. It is leaving because the world that had made it a good idea has changed. For years it was the perfect compromise: solid enough to look modern, flexible enough to accompany systems that needed to evolve without throwing away everything that already existed.
The point is that technical compromises age badly when the context stops protecting them. And that is exactly what happened to RC4. Over time, cryptographic weaknesses emerged that became harder to ignore, while attacks around them became more practical, more accessible and better alternatives became available. It is no coincidence that RC4 began to leave the stage in several areas: in 2015 the IETF banned its use in TLS, in 2020 its use in SSH was formally deprecated, and in the Wi-Fi world the industry had long been moving toward WPA2 with AES, leaving behind the transitional solutions that still relied on the same underlying cipher.
This brings us to the Microsoft case, which should not be read as an exception, but as one of the last chapters of a story that had already started elsewhere. In the official post Beyond RC4 for Windows authentication, Microsoft openly states that RC4 is susceptible to attacks such as Kerberoasting and that secure Windows authentication no longer needs it, because AES has been available for years on all supported versions. In other words, RC4 does not stop working: it reaches sunset when the present no longer has good reasons to keep using it.
How Microsoft is accompanying RC4 off stage
If we look closely, this story does not begin this year. Microsoft had already started moving the center of gravity away from RC4 at least in 2022, when the updates related to CVE-2022-37966 made AES the default for session keys on accounts without explicit settings. It was not the final retirement yet, but the signal was already clear: the old compromise was losing ground. The most recent documentation also recognizes this openly, explaining that the change has already significantly reduced the use of RC4, although without eliminating it completely.
2025 and especially 2026, however, change the music. We are no longer around progressive hardening or of a technical detail that almost disappears inside a cumulative update. We are at the point where Microsoft decides to make the direction explicit and to mark it in very readable phases: first audit, then a change in default behavior, and finally the end of implicit tolerance. It is as if for years there had been a “work in progress” sign at the entrance, and only this year someone had really started closing the road.
At that point, the turning point becomes July 2026. Because that is when the timeline stops being a sequence of warnings and becomes a real deadline. KB5073381 says that the updates released in that period will programmatically enable the Enforcement Phase; the operating procedure we are using in the field translates it even more clearly: no comfortable rollback, no return to the past by inertia, no implicit fallback left there to protect what no one has yet put in order. From that moment on, RC4 continues to live only where someone has kept it explicitly, account by account, exception by exception.
And this is exactly where things become interesting. Microsoft provides official tools to address the problem: more visibility in the logs, guidance on how to detect and remediate RC4 usage, and PowerShell auditing scripts referenced in the official documentation. But the reality is that these tools, on their own, risk returning a very noisy picture.
Microsoft’s own documentation explains that RC4 can still appear for different reasons: legacy systems, accounts without explicit settings, incomplete configurations. And field experience adds an even more concrete detail: raw large numbers can be misleading, the absence of detected RC4 traffic is not always conclusive, and some categories, such as accounts “without AES keys” read too superficially, risk making the problem look larger than it really is.
That is why the next step cannot be only technical. The approach must be broad, yes, but above all pragmatic: wide enough not to miss the weak signals, lucid enough not to be overwhelmed by background noise.
Because in enterprise systems the past almost never presents itself in an orderly way. It hides in habits, inherited settings, defaults left there for years, behaviours that seem normal only because no one had looked at them closely anymore.
And that is where we need to start, if we really want to reach the key knots and begin untangling the thread.
What is emerging from the analyses we are doing
When you move from theory to real systems, the matter immediately stops looking linear. On paper, the problem may almost seem trivial: Microsoft changes a default, RC4 leaves the stage, and whoever is left behind adapts.
More than once, I have heard sentences like: “I am pretty sure this will not impact us”. And every time I wondered where all that certainty came from.
In practice, enterprise systems never think that cleanly. They think through habits, layers, inherited settings that keep producing effects long after everyone has forgotten why they were put there in the first place. And it is precisely in this gray area that RC4 continues to leave traces.
Looking at the data emerging in the field, the first thing you understand is that raw numbers only help up to a point.
Starting from the big picture, the view almost always narrows around the same sensitive points. Not so much the large indistinct volumes, but a handful of service accounts with SPNs, historical passwords that were never rotated, some non-Windows or not clearly AES capable systems, and all those pieces of infrastructure that have been living quietly for years precisely because no one had a reason to touch them anymore.
Around them, hundreds or thousands of user and computer objects that can be handled with a pragmatic approach, but that tend to hide the focal knots from view.
In the reports we are producing, the logic often comes back to the same point: the real work is not in the big numbers that look impressive in a table, but in a few objects that still hold heavy and poorly visible dependencies together.
Then there is another aspect, perhaps the most insidious one: the absence of strong evidence does not automatically mean the absence of problems.
In more than one case, event collection turned out to be limited or partial, and the recommendation is to set a sufficiently wide audit window when the available data is not enough to close the picture.
Here too the usual paradox of legacy systems comes back: the past does not make noise when it is truly present. In fact, it often stays quiet until someone decides to look more carefully.
That is why, the further we move on, the clearer the point seems to me: addressing RC4 does not simply mean “looking for where it appears” and turning it off everywhere. It means reading systems through a lens wide enough not to lose context, but pragmatic enough to identify the knots that really matter.
There is no need to chase every reflection. What matters is understanding which signals lead to real dependencies, which ones are only background noise, and where it makes sense to intervene without being swallowed by the tangle.
And this is exactly where field experience becomes vital: because in legacy systems, the problem is rarely where you see it immediately. More often, it is where no one thought they still needed to look.
Practical notes from the field
At this point it is worth going down one more level. Because data helps, but concrete examples are what make it clear where the past is still carrying weight. In this case I asked my colleague Mattia Grandi for help, and he summarized the most technical aspects well in his article.
Speaking of emblematic cases, the first one that comes to mind is Kemp Loadmaster, very often used for republishing with Kerberos Constrained Delegation, or KCD.
This is one of those cases where the Kerberos implementation is not Windows native. Therefore, the algorithm change must be handled with care, clearly identifying the operating sequence and a dedicated maintenance window. It is a common pattern in third party Kerberos implementations.
Looking then “toward the cloud”, we may have to deal with the historical AZUREADSSOACC$ account, used by the Seamless Single Sign-On feature for Entra ID.
It is a classic example of a cloud driven implementation that, precisely because it was born with a historical default on RC4, now shows all the limits of that choice.
We must also remember that Kerberos, by its nature, is not confined to a single domain, but often crosses boundaries through Trusts.
These too are just as sensitive to the algorithm that has been configured for them: if I have a Trust that does not support AES, or that does not have AES configured, the closure of RC4 will “break” it as if it were any ordinary PC, but with much broader effects.
Finally, let us talk about legacy systems, whether they are Windows Server 2003 machines that survived the decades or third-party implementations that do not support AES, such as the immortal AS/400 systems.
In these cases, it will not always be possible to shut down RC4 cleanly and immediately.
Instead, it will be necessary to investigate precisely what Kerberos is actually being used for. This is the only way to manage targeted and conscious exclusions.
As you can see, the field of action widens quickly. The risk is not only breaking something, but losing control of the situation or focusing effort where it is not really needed.
What we learned from the sunset of RC4
The first lesson left by the sunset of RC4 is only apparently simple: the most successful technical compromises are also the hardest ones to retire. RC4 survived for so long not because it was perfect, but because for years it was fast, practical, compatible and light enough to become invisible. And when a technology becomes invisible, it stops being discussed long before it stops producing real effects.
The second lesson concerns the way we treat the past in enterprise systems. Ignoring it does not make it harmless. It only makes it harder to recognize when it comes back to ask for payment. In the case of RC4, that bill also has a precise date: July 2026. Anyone who reaches that point still depending on this old compromise will not be facing a mystery, but widely predictable authentication failures.
This does not mean approaching the subject ideologically. In real systems there are always exceptions, dependencies, appliances that do not follow the timing of the rest of the infrastructure, systems that are truly not AES capable and integrations that require a slower transition. But precisely because these exceptions exist, they must remain what they are: real exceptions, documented, approved and reviewed. Not a new normal behind which inertia can continue hiding.
Because compatibility and inertia are not the same thing. Compatibility is a conscious design choice: it helps a system evolve without breaking it. Inertia, instead, is what remains when that choice stops being governed. It is the default left there for too long, the service account never reviewed, the trust no one touches anymore, the legacy system that keeps working not because it has been understood, but because no one has yet had the courage or the time to look inside it.
After all, it is the same thread that runs through all these chapters. The guardian of AdminSDHolder, the trusts created to give shape to trust, the Domain Controller that seemed to lie: every time, the point was not that the system was broken. The point was that the system kept doing what it had been designed to do, while we had lost part of the memory of that design.
RC4 tells the same story from another angle. It is not the monster to erase from history, nor the symbol of a catastrophic mistake. It was a good answer to a problem of its time. Only time, at some point, changes the question. And when the question changes, continuing to give the same answer is no longer compatibility: it is stubbornness.
Maybe this is the most important lesson of its sunset: we cannot expect legacy systems to disappear on their own, nor to spontaneously stop influencing the present. We need to look at them, understand them, decide what to preserve and what to accompany off stage. Without nostalgia, but also without arrogance. Because many of the things we call legacy today were, in their moment, excellent solutions.
The problem begins when we keep treating them as if the world around them had not changed.
RC4 had a long, useful and in some ways surprising life. Now, however, sunset is no longer a metaphor: it is a deadline. And as often happens in enterprise infrastructures, the difference between an orderly transition and an avoidable incident lies entirely in deciding whether to deal with it while there is still light, or wait for the dark.