“The End of the World!?!” That’s what the cover of TIME Magazine said for its January 18, 1999 issue.

Over two decades ago, the industrialized world was gripped by panic over the so-called Y2K bug. Also called the Millennium Bug, the year 2000 problem, Y2K problem, the Y2K glitch and other labels, some feared the problem might cause computers to crash, jetliners to fall from the sky, hospital equipment to stop working and the global financial system to grind to a halt after the New Years Eve that rang in the year 2000. It was a genuinely scary time that many have now largely forgotten.

Here’s what caused the panic. Most legacy systems built in the 1960s, 1970s and 1980s used only two digits to encode the year — for example, the clocks inside microprocessors and software registered the year 1999 as “99,” based on the lousy assumption that “19” would always come before that. When those two digits clicked over from “99” to “00” — the computers would register the year as “1900.” Computer systems that ran everything from airline schedules to hospital equipment and military hardware would be thrown into chaos.

Programmers and systems designers knew that a four-digit year would be better. But they chose two-digit years because, back then, storage was expensive. Reading that storage was slow and minimalism in programming was a high virtue. In any event, everyone assumed that the year 2000 was far into the future and that surely by then we’d all have jet packs, eat food in pill form, wear futuristic silver uniforms and have long phased out the old mid-century computer systems with their old-timey two-digit years.

In the ensuing decades, storage grew cheap and legacy systems lingered. By the early 1990s, concern started to emerge. The trickle of commentary on the problems became a flood by the late 1990s. And as the year 1999 dawned, a full-blown panic set in.

Many people worked hard to implement workarounds. For certain industries, laws mandated these fixes. And yet other people didn’t patch, fix or update their systems at all.

When the turn of the millennium happened, catastrophe failed to strike. Did the efforts to patch avert disaster? Or was the Y2K scare wildly overblown?

Many even called the Y2K scare a hoax.

But what really happened? And what are the lessons for cybersecurity from the entire Y2K event?

Understanding the Y2K bug

In the early to mid-1990s, when concern in the technology press started to emerge — eventually by the end of the decade spilling over into the general news media — it started to dawn on the public just how many everyday systems were dependent on computers and microprocessors. What would happen with traffic lights, elevators, air traffic control systems, ATMs, nuclear power plants, nuclear missile complexes, communications satellites and a thousand other objects not normally associated with personal computers and servers when those systems didn’t know what century it was?

People often express the Y2K bug as an issue with software, but the bigger concern was embedded systems and microprocessors. What might they do when they encountered an impossible date? While you can patch software, you might have to replace embedded hardware systems at an enormous cost. In the mid-90s, pundits predicted that the Y2K bug might cost as much as $600 billion to fix. Would the cost of fixing exceed the cost of not fixing? Nobody could be sure.

A more sophisticated understanding of how the world of information systems works suggested that the web of interdependent systems involved unknowable outcomes from random points of failure. Would multiple arbitrary failures create a cascading series of crashes? Would the world’s computer systems fall like dominoes?

In the waning years and months of the 1990s, it became clear to the public that even experts couldn’t predict what might happen. Adding to the fear of actual systemic failure was the fear of human action at scale. Would people hoard food, creating scarcity? Could there be a run on the banks, triggering another Great Depression? Might failures cause misunderstanding, leading to nuclear war?

Preppers hastily constructed bunkers and built survivalist compounds, and stocked up on provisions. Fortunately, most people didn’t act in panic.

Fixes for the Y2K bug in software involved a variety of workarounds, from expanding the year field from two to four digits to instructing programs to assume that any year between zero and 50 was preceded by “20” rather than “19.” “Y2K compliant” became the buzzword of 1999.

The dash to fix the Y2K bug proved costly, even contributing to some companies going bankrupt or going out of business.

People fixed many bugs. Many remained. The world did what it could. And on New Year’s Eve, everybody partied to ring in 2000. Because at midnight, the whole world might crash.

What happened when the year 2000 arrived?

The world didn’t crash. While catastrophe never arrived, some isolated problems did:

• The first baby born in the new millennium in Denmark was 100 years old at birth, according to the hospital computer system
• Millions of unusable German bank cards had to be replaced
• A man returning a VHS tape to a video rental store in New York was billed for $91,000 dollars because the system thought he was returning it 100 years late
• An alarm rang harmlessly at a Japanese nuclear power plant two minutes after midnight
• Bulgarian police documents came out with expiration dates on the 29th of February in years that were not leap years
• U.S. spy satellites malfunctioned, sending unreadable data, for three days. (The glitch happened not because of the Y2K bug itself, but a patch that was supposed to fix it)
• Computer errors delayed trains in Norway.

Thousands of small, largely inconsequential problems occurred. Some happened because of fixes to the bug, rather than the bug itself.

It was mostly a few obsessed English-speaking countries that felt concerned and took action. The rest of the world largely ignored it. And those countries that ignored it were fine, too.

As the first days of the year 2000 turned to weeks and months, a consensus emerged in the public conversation that the Y2K bug was actually no big deal. People criticized alarmists and scrutinized money used for precautions. And then the world moved on.

What cybersecurity lessons can we learn from Y2K?

The Y2K event was unique in human history and can provide rare insights into how computer systems and microprocessor-based devices function under unusual and unpredictable stress. And that should be instructive for cybersecurity professionals.

We can take seven lessons from the Y2K bug today:

1. Fixing a vulnerability may create a new vulnerability. Many of the problems came from the patches and fixes for the Y2K bug, not the bug itself. While testing for Y2K bug problems was thorough, testing the fixes was sometimes less so. Always test the fixes thoroughly.
2. Fixing your own vulnerabilities also improves cybersecurity for connected systems. With the Y2K bug, the patches applied in the United States for global systems controlling financial systems, for example, protected countries that took far less action to prepare for Y2K. Likewise, the cybersecurity fixes applied by a supplier may also help protect you, and vice versa. Take a big-tent approach to cybersecurity and make sure everybody is doing their part.
3. Don’t expect everyone to give you credit for averting disaster. Cybersecurity people are in an unhappy position, and it’s just part of the job. If you fail to avert disaster, many will blame you for the failure. But if you succeed, they may blame you for being alarmist, spending too much time and money on the problem and misrepresenting a threat. The best you can do is do the best job you can communicating both the risks, the remedies and the benefits of averting crises after the fact.
4. The biggest risks come from not one, but multiple points of failure or vulnerability. It’s easy to form tunnel vision about vulnerabilities. But most major cybersecurity failures result from multiple points of failure — a lack of employee training combined with inadequate tools, for example. Think holistically.
5. Testing is everything. During Y2K, a regulation that forced mandatory testing enabled the fixes that prevented the most serious problems. Red-team exercises and their many variants are valuable exercises for figuring out in advance where the vulnerabilities lie. Be obsessive about testing.
6. Investment to prevent catastrophe is expensive but often money-saving in the long run. Most of the damage caused by cyberattacks is, in the end, expressed in financial terms. But the costs of preventing or minimizing cyberattacks can also be costly. Make sure the cost-benefit analysis of cybersecurity investment is clearly stated in dollars and cents (as well as in other contexts, such as reputational damage). While cybersecurity tools, programs and staff cost money, breaches and attacks can cost far more.
7. Old systems can create new problems. Legacy systems or programming languages that had fallen out of vogue meant that the people charged with fixing the problem may not understand how they worked. That was certainly the case with the Y2K bug. (Companies dragged retired programmers out of retirement to help fix the problem.) While it’s easy to ignore or overlook legacy systems that have been churning away for many years, always consider how they might contribute to new problems in the future.

The Y2K bug turned out, in the end, to not bring about “the end of the world,” as the TIME Magazine cover implied. But, skilled people mitigated the worst effects. It took serious action and investment, lots of testing and exploration, plenty of patching and fixing and an “all hands on deck” approach to problem-solving. All of these things are valuable lessons for cybersecurity professionals today.