The Playground Secrets Arms Race
Two friends, Alice and Bobby , decide they need a way to pass secret notes without their frenemy, Mallory, finding out. Mallory’s the kind of kid who always wears a black hoodie and somehow knows everything. So annoying! Alice and Bobby’s plan is brilliant, at least by 2nd grade playground standards: they’ll invent a super secret code. They pick something easy: a “shift code.” For today, every letter in the alphabet moves three places to the right. A becomes D, B becomes E, C becomes F. Tomorrow, they’ll pick a different number to shift. Perfect! Alice giggles she writes their first coded note: “PHHW DW WKH VOLGH.” It’s a very important message for Bobby: “MEET AT THE SLIDE.” They’re so confident in their super secret code that Alice writes her message for Bobby right on the corner of the classroom whiteboard for everyone, including Mallory, to see. That’s part of the fun: everyone can read the note, but only they can understand it. But Mallory suspects what Alice and Bobby are up to. By lunchtime, Mallory cracked the code. All she had to do was try a few shifts until the words made sense. There are only 25 possibilities, after all. She strolls out to recess with a grin. “Hi guys!” she says, popping out from behind the slide.
Alice and Bobby give each other confused looks, “How did she know?” Before school the next day, Alice and Bobby regroup. “Okay,” Bobby says, “we need to make this harder.” This time, they decide to use a random letter swap that changes every day. E could be Q today, but X tomorrow. They each write down the letter mappings neatly on a pad of paper, rip off the sheet, and save it in their backpacks. Bobby then writes his encoded message for Alice on the whiteboard: “SWINGS AFTER LUNCH.” Now, surely, Mallory’s been outmatched! Not so fast – Mallory’s no fool. After she saw Bobby write his message to the whiteboard, he noticed him throw something into the trash. “Hmmmm… what do these letters mean,” Mallory pondered. She realizes how the game has changed, cracks the code, and races to grab the best swing before Bobby and Alice show up, now with even more shocked expressions on their faces.
Alice and Bobby realize their mistake and refine their process again. “We’ll rip it up next time,” Alice says. They pinky promise to tear each day’s mappings into tiny pieces after they use it. Until Mallory, proving herself worthy of a cybersecurity PhD someday, rubs a pencil over the next page in the pad of paper they used to reveal the indentations left by their pen, and shows up later during recess at the big oak, smirking. Alice groans. Bobby sighs. “We’ll never win.”
The Real Story of Encryption
This playground arms race parallels how the history of real-world encryption has played out. Every generation invents a clever way to protect secrets, and every generation of adversaries then figures out new ways to compromise them. Mallory first used brute force, then she found an implementation flaw, and then she even used a “side channel” exploit with the indentations to defeat Alice and Bobby’s secret code; all techniques that have been used for ages to defeat encryption.
And just like Alice and Bobby, modern cybersecurity professionals are always trying to stay one step ahead of their own Mallorys. But, each leap in computing power and creativity continually reshapes what “secure” encryption really means. Today, encryption is everywhere: in your browser, your phone, your car, your smart fridge. It’s the quiet guardian that keeps your bank login safe and your online chats private. And for the most part, it’s been so remarkably reliable for so long now that most people don’t even think about it. The Mallorys of the world, it seems, are on a losing streak. And that’s kind of the problem.
Encryption Has Been Too Good for Its Own Good
Modern digital encryption has been very effective for a very long time. The past two decades have seen plenty of cybersecurity crises – ransomware, identity theft, social engineering, supply chain exploits – but remarkably few serious events have stemmed from someone actually compromising the math behind encryption itself. When encryption-related issues did make headlines, mostly notably in the early 2010’s with memorably named vulnerabilities like Heartbleed, POODLE, and BEAST, it wasn’t because the fundamentals behind encryption failed. For the most part, these issues were related to software design flaws or implementation bugs. The complex math concepts that form the basis of encryption were never really broken, and they continued to be considered quite strong.
So, while these vulnerabilities were serious, for most companies the only impact to them was the time it took to update a few libraries or reconfigure a webserver. Nothing worse than any other technology firedrill. But that “we’ll fix it when it breaks” attitude has also led to a kind of mass amnesia. We’ve forgotten how to think about encryption, and data protection more broadly. For many businesses, data protection is a checkbox. “We use TLS (Transport Layer Security) 1.3.” “We encrypt data at rest.” Beyond some occasional package updates, it’s not much more. It’s a static concept, not strategic. In practice, most developers, security teams, and vendors have never in their careers had to go back to the drawing board and do a wholesale reexamination of how and where encryption is used in their systems. We’ve all gotten a little too comfortable, like Alice and Bobby smugly posting their first “secret” code on the whiteboard. We’re confident it works, because it has worked for a long time. The tools, technologies, and mathematical foundations we depend on today to make encryption work are guaranteed to eventually weaken or break as techniques and hardware evolve. That may actually be ok, if you believe the system or software you’re building will be retired before the encryption it uses becomes outdated. But that introduces two difficult-to-manage problems: things you build tend to stay around far longer than anyone anticipates, and encryption methods can weaken quickly and unexpectedly. If your systems are built in a way that makes it painful (or impossible) to swap out encryption methods when the time comes, you’ll be stuck. That’s why modern security thinking is starting to shift toward a new priority: designing architectures that expect that encryption will need to change substantially over time. The goal is to build flexibility right into your systems so you can update, replace, or reconfigure encryption technology as threats evolve without tearing everything apart. That flexibility has a name: crypto agility .
What Crypto Agility Really Means
Crypto agility means designing your systems and code so that encryption methods can easily evolve with minimal operational or business impact.
It’s a mindset, a way of designing architectures that are built for change and can adapt without breaking. It’s also what forward thinking technology leaders are starting to do to protect their companies. Consider this: if there was a massive zero-day encryption vulnerability announced tomorrow, could you deal with it easily? And not just by updating a package or two: could you identify everywhere a particular type of encryption is used, in applications, APIs, databases, backups, IoT devices, and vendor integrations, and if necessary change it to something completely different without breaking your entire infrastructure? For most organizations, that’s a hard no. Where would you even start?
You’d start by wishing for an inventory you don’t actually have, which is the first problem crypto agility aims to solve. Knowing what encryption you use, where you use it, and being able to change it without tearing everything apart is foundational to everything.
Start with what you build. When your development team (or AI!) writes code that encrypts customer data, processes payments, or handles authentication, are those cryptographic decisions hardcoded throughout your application, or can they be changed from a central configuration?
Then there’s the software many companies have to manage but didn’t write. These are your commercial or open source databases, web servers, CRMs, and other systems. Do you have an inventory of what encryption each system uses and whether it can be reconfigured or upgraded? When your database vendor announces they’re deprecating TLS 1.2, do you know which of your services will break and how long the migration will take?
Finally, there’s everything outside your walls: payment processors, authentication providers, cloud storage, analytics platforms, and dozens of other services your application connects to. You may not control their cryptographic choices, but you depend on them. Crypto agility here means knowing which vendors use which encryption standards, having visibility into their security roadmaps, and maintaining the flexibility to switch providers if necessary. When a vendor is slow to adopt new encryption standards, that becomes your vulnerability.
The common thread? Inventory and planning. You can’t upgrade what you can’t find, and you can’t respond quickly to cryptographic changes if your systems are brittle. Most companies discover these gaps when it’s too late.
The Calm Before the Quantum Storm
So what’s the next Mallory waiting around the corner? It’s not even Mallory, it’s more like her genius older cousin Chad at NASA is working on. It’s something called quantum computing . If you haven’t encountered this yet, you’re not alone.
To grossly oversimplify, engineers are figuring out how to build computers that use subatomic physics to solve complicated mathematical problems in an entirely novel way. Quantum computers are able to explore many possible paths to a solution at once, and then use the tiny wave-like effects of subatomic particles to make the most promising paths stand out. This process allows you to gain mathematical insights that were previously impossible with regular (or “classical”) computers.
If that made zero sense, then imagine this: You send one million mice into a maze at the same time while you listen with an ultra-sensitive microphone. Their tiny footstep-vibrations fizzle out in the dead ends, but along the path that leads to the exit they line up and make that route resonate louder. All you have to do is follow the loudest hum to find your answer. That’s basically what quantum computing does. (Give or take a few details. Sorry, physicists!)
It sounds like science fiction, but it’s 100% real. Quantum computers are in active, well-funded development by some of the world’s biggest tech companies.
At this moment, quantum computers are all still very small-scale and experimental. Their potential is clear, but for now they can’t yet do the heavy duty computations that will solve any “impossible” math problems. And that may be a good thing for now, because some of the “impossible” math problems they will be able to solve form the bedrock of modern encryption!
The National Institute of Standards and Technology (NIST) and the National Security Administration (NSA) estimate that within 10 to 20 years, quantum computers could be powerful enough to break today’s encryption standards. In fact, in 2022 the NSA recommended software companies prefer quantum-resistant cryptography by 2025 , and it wants all major data-handling industries to be quantum-resistant by 2033!
Here’s the reason this is so important: quantum computers will make child’s play of the “hard” math used by two-party encryption and will be able to quickly determine the keys necessary to decrypt messages. Every web page a browser requests, every database query, every file transfer – all as if it was sent in plain text!
The volume of potentially affected data is huge. Virtually everything shared between two systems (browsers, email clients, websites, or companies) will be at risk. The exception is data encrypted with a key that’s only known to you, like inside a database.
And even before that happens, there’s already a serious risk emerging today: attackers can save encrypted data now, and simply decrypt it later once quantum technology catches up. It’s called “harvest now, decrypt later.” Highly sensitive encrypted data, like trade secrets, government communications, medical research, could already have been intercepted and saved by adversaries, sitting in storage somewhere, waiting for the day a powerful enough quantum computer makes it readable. But there is some good news. The threat posed by quantum computing has been anticipated for decades, and cryptographers have been working very hard to create entirely new algorithms designed to resist cracking by both quantum and classical computers. Even better, NIST released the first officially approved versions in 2024: Federal Information Processing Standards (FIPS) 203, FIPS 204, and FIPS 205. These are already being tested and implemented by security-forward companies. The bad news? For many companies, migrating to a new encryption standard will be a hard task and take time. Think major, months or quarters-long projects.
Even worse, I believe most companies are not aware of this. About 50% of our clients didn’t know this threat was coming until we brought it up!
Building Crypto Agility for the Quantum Era
The looming quantum computing threat is the kind of challenge that rewards those who prepare early and punishes those who wait. Adapting a crypto-agile mindset now will help you address the quantum transition and will also position your organization to adapt and stay on top of whatever comes next.
Here’s how to get started:
Take an Inventory of your Encryption, Before You Need It
You can’t protect what you don’t know about. Start by mapping where encryption is used in your systems. This means more than just “we use HTTPS.” It means knowing which TLS versions your services use, what database encryption you’ve enabled, how your backups are protected, which APIs rely on specific cryptographic libraries, and what your third-party vendors are doing.
This inventory doesn’t need to be perfect on day one, but it needs to exist and be maintainable. Create a living document or system that tracks your cryptographic footprint. If you don’t have a dedicated security leader doing this internally, this is the kind of assessment our Virtual CISOs can run. When the quantum deadline gets real, you’ll be glad you know where to look.
Examine Risks To Your Data
Let’s now consider the consequences of “Harvest Now, Decrypt Later.” It is imperative to also inventory your data, and to examine how that data is encrypted when stored and when transmitted.
Zero in on your most sensitive data that has a long shelf life and would still be damaging to you if it was exposed in a couple years: health care data (PHI), intellectual property, financial records, and the like.
Make your systems Quantum Ready
Sensitive data is most at risk when transmitted , often using protocols like TLS (the protocol most often used with HTTPS). The most important first step is to become “Quantum Ready” and start planning for the use of TLS 1.3 only . TLS 1.2 (or worse) should no longer be allowed, even as a secondary fallback option, because it does not support the newer, safer FIPS algorithms. Turning off old TLS versions and only allowing TLS 1.3 may make some IT folks nervous, but it is an important and necessary step.
To become “Quantum Safe ” though requires you to do just a little bit more. When you configure TLS, you give it a list of acceptable algorithms to use, so the next step is just to add the FIPS-approved ones to its list, most notably one called “ML-KEM”. At the moment, this is packaged up as a hybrid “new + old” encryption algorithm, so if there are unexpected weaknesses with ML-KEM, it will still have the protection of the older (non-quantum safe) algorithms at least. Nifty trick, cryptographers!
In practice, only a few websites from big companies like Cloudflare and Amazon have fully deployed Quantum Safe algorithms, as it is a significant change that requires some important technical considerations. But, that will change rapidly as more companies prepare for the transition. For now, focus on the challenges of becoming Quantum Ready by deprecating all use of TLS 1.2 or earlier. Your jump later on then to Quantum Safe ML-KEM will be far easier!
Design for Changeability, Not Just Security
When you’re building new systems or refactoring old ones, ask yourself: if we had to swap out this encryption method next year, how hard would it be?
Centralize cryptographic decisions through configuration rather than scattering them throughout your codebase. Use abstraction layers and libraries that let you change algorithms without rewriting application logic. Build systems that can run multiple encryption methods side-by-side during transitions. These are good engineering practices that will serve you through every future security evolution.
Special note for companies that are aggressively using AI to write code: be very careful about how you instruct AI coding tools so they do not create a spaghetti bowl of encryption you’ll have to untangle later. Anticipate that you will have to rip out and replace all of your encryption algorithms at some point! Remember, the keyword is crypto agility.
Start Your Post-Quantum Migration Planning Now
Don’t wait for quantum computers to arrive before you start planning. The new Quantum Safe “post-quantum cryptography” (PQC) FIPS standards are already here. Begin experimenting with them in non-critical systems. Run proof-of-concept migrations. Identify which of your systems will be hardest to upgrade and start making a plan for those first.
Remember, this won’t be a flip-a-switch moment. Large organizations may need years to fully transition. The companies that start earliest will have the luxury of time to test thoroughly, work through unexpected issues, and migrate methodically. Those who wait will be caught flat footed when this becomes a customer demand.
Engage Your Vendors and Partners
You’re not in this alone. Talk to your technology vendors about their post-quantum readiness. Ask your cloud providers about their migration timelines. Include crypto agility requirements in new vendor contracts. Build relationships with partners who are thinking ahead about this problem, not those who are pretending it doesn’t exist.
If you use strong encryption but your vendor uses weak encryption for the same data, you are at greater risk! A chain is only as strong as its weakest cryptographic link.
Test, Validate, and Test Again
When you do start migrating to quantum safe algorithms, don’t assume it will go smoothly. These new algorithms behave differently. They often use larger keys, require more processing power, and can introduce unexpected compatibility issues. Test in staging environments, validate performance impacts, and have rollback plans.
Back to the Playground
Remember Alice and Bobby? Their problem wasn’t that their codes were bad. Each one was actually pretty clever for a couple of second graders! Their problem was that they built systems that couldn’t adapt. Every time Mallory found a weakness, they had to start over from scratch.
Modern organizations face the same risk. If your encryption architecture is rigid, scattered, and undocumented, you’ll be starting from scratch when quantum computers arrive.
But if you build with crypto agility in mind, you’ll be prepared to adapt. You’ll know where your secrets live, you’ll be able to change your methods quickly, and you’ll be ready for whatever the next Mallory or Chad brings to the playground.
The quantum era is coming. The question isn’t whether you’ll need to adapt your encryption, it’s whether you’ll be ready when the time comes. Start building that readiness today, and you won’t just survive the transition to post-quantum cryptography. You’ll be prepared for every cryptographic challenge that follows.
At Fractional CISO, we help organizations strengthen their security posture for the long term. Practical, scalable, and future-ready. If you’d like to talk about assessing your encryption landscape or building crypto agility into your roadmap, we’re here to help.
Want to get great cybersecurity content delivered to your inbox? Click here to sign up for our monthly newsletter, Tales from the Click.