Cryptography as an Attack Surface

Source: https://www.magnific.com/free-photos-vectors/digital-lock

“We use encryption.” Few phrases instill such a false sense of security in an organization. It’s said in compliance meetings, written into security policies, and repeated during audits. And in most cases, it’s technically true but practically useless. Because the problem is almost never whether an organization uses cryptography. The problem is how it manages it, how it operates it, and how long it’s been since anyone reviewed it.

In practice, cryptography does not behave like a padlock that is installed once and protects forever. It behaves like an attack surface: a set of interconnected components—algorithms, keys, certificates, protocols—that an adversary can probe, exploit, and compromise. Treating it as a checked box is, paradoxically, what turns it into a vulnerability.

The second most critical risk and the one most often overlooked

OWASP, the global authority on web application security, regularly publishes its Top 10 list of critical risks. As has already been discussed in detail on Cyte (https://www.cyte.co/post/owasp-top-10-2021), this list serves as a diagnostic tool for identifying the most prevalent security flaws in applications. What deserves attention here is the position occupied by Cryptographic Flaws: second. Not eighth. Not a marginal mention. Second. Above SQL injection, above cross-site scripting, above most of the vulnerabilities that grab headlines.

Source: https://owasp.org/Top10/2021/es/

¿So what does this category cover? It’s not “someone cracked AES-256.” That, in practice, almost never happens. What does happen, with alarming frequency, is much more mundane: sensitive data traveling unencrypted because “it’s internal traffic”; obsolete algorithms like MD5 or SHA-1 that remain in production because no one updated them; encryption keys hardcoded into source code or stored in unprotected repositories; expired or misconfigured TLS certificates that are renewed only when the browser displays an error.

The irony is that these flaws don’t require a sophisticated attacker. They require a patient attacker—or simply one who knows where to look. The tools to identify these weaknesses are within reach of any offensive security professional—and, of course, any motivated adversary.

Cryptography doesn't fail—it's abandoned

There is a distinction worth making explicit: cryptographic failures are rarely mathematical. They are operational. The algorithms we use today—AES-256, RSA-2048, elliptic curve standards—are mathematically sound against classical computing. The problem isn’t with the algorithm. It’s with everything surrounding it.

Cryptographic keys have a lifecycle: they are generated, distributed, used, rotated, and retired. In most organizations, that lifecycle exists in a policy document that no one consults. In practice, keys are generated once, copied across environments, never rotated, and when someone asks “where are our keys?”, the answer involves searching through configuration files, scattered environment variables, and the memory of whoever created them three years ago.

This is not a theoretical problem. It is the actual state of cryptographic management in a significant proportion of organizations, including those that handle financial, medical, and government data. Cryptography was implemented, it checked a box on the audit checklist, and then it was essentially abandoned. No one broke it. They simply stopped taking care of it.

The due date that no one checks

If today’s operational failures are already cause for concern, the dimension added by quantum computing turns that concern into an urgent matter. There is a documented and active strategy known as “Harvest Now, Decrypt Later” (HNDL): malicious actors both state and non-state are intercepting and storing encrypted traffic today, with the expectation of decrypting it once quantum computing makes it possible.

This fundamentally changes the risk calculation. The question is no longer “Can someone break my encryption today?” but “How long does the data I’m encrypting need to remain confidential?” For financial records, medical records, intelligence information, or intellectual property, the answer is decades. And if the encryption protecting them today will be vulnerable tomorrow, then the breach has already occurred. It just hasn’t materialized yet.

The RSA and ECC algorithms that underpin virtually all asymmetric encryption in use today are vulnerable to Shor’s algorithm, which can be executed on sufficiently powerful quantum computers. We are not talking about an abstract possibility: NIST has already published the first quantum-safe cryptography standards (ML-KEM, ML-DSA, SLH-DSA) and has set a goal to phase out RSA and ECC by 2035. The transition is not a speculative gamble; it is a roadmap with a set timeline.

Source:https://www.spinquanta.com/news-detail/what-is-a-quantum-chip-and-how-it-works-the20250103060123

Crypto-agility: the capability, not the project

Faced with this situation, the instinctive response of many organizations is to ask, “Which algorithm should we switch to?” But that question, while legitimate, is misguided. The problem isn’t the current algorithm. The problem is the inability to change it.

This is what is known as crypto-agility: the organizational ability to rotate algorithms, migrate keys, and adopt new standards without halting operations. It is not a product you buy or a one-time project. It is an ongoing security posture that requires centralized visibility into where keys are located, which algorithms are in use, when they were last rotated, and which systems depend on each one.

Without that visibility, quantum-safe migration becomes what IT teams fear most: a massive, costly transformation project with the risk of operational disruption. With it, it’s a more significant rotation, yes, but a manageable one. The difference between an organization that can migrate to quantum-safe standards in months and one that needs years isn’t in its budget. It lies in whether it treated its cryptography as a living infrastructure or as a checkbox from the past.

At Cyte®, this is precisely the philosophy that guides the design of solutions like Crypto-Vault®: not to offer just another algorithm, but to build the organizational capacity to operate, audit, and evolve cryptography as a living component of the security architecture. Centralized key management.

The door is open and the key is in the lock

Cryptography is not a solved problem. It is a living system that requires constant attention, clear governance, and the ability to evolve. Every key that hasn’t been rotated, every deprecated algorithm still in production, every forgotten certificate is an open invitation—not to tomorrow’s attacker, but to today’s.

Treating cryptography as a checkbox is like leaving the door open with the key in the lock. And in the quantum era, that key has an expiration date.