I have interviewed a lot of engineers and product marketers at engineering conferences and trade shows. Most are quite good. Some are great. Every once in a while, someone stops you cold.
That happened to me at Microchip Technologies’ booth at Sensors Converge earlier this year. I was chatting with Brette Mullenaux, an engineer product marketer focused on security ICs, when she launched into an explanation of post-quantum cryptography that was, honestly, the clearest I have ever heard. And I have been chasing this topic for a while. I read books about quantum computing. I commissioned a series on post-quantum firmware security. I find it equal parts fascinating and slightly terrifying.
Brette made it click in a six-minute booth conversation.
What struck me was not just her technical depth, though that was considerable for someone early in her career. It was how precisely she communicated it. No hand-waving. No jargon for its own sake. Just clean, logical explanation of a subject that most people in the industry are still struggling to get their arms around.
I asked her on the spot if she would do a Q&A for EEWorld. She said yes. Here it is.
How did you come to specialize in post-quantum cryptography at this stage of your career, and what drew you to it?
Brette Mullenaux
In my role as a hardware security technical marketer, I track emerging security trends and regulations that directly impact product design and long-term roadmaps. My interest in post-quantum cryptography (PQC) took shape in early 2025, when Microchip was preparing to launch its first PQC-enabled embedded controller. That was a turning point where it became clear PQC was no longer theoretical, but an urgent, real-world requirement.
What stood out was the emergence of two types of customers. Some, with deep security expertise, quickly began redesigning for upcoming product cycles. Others were trying to adopt PQC without fully understanding the system-level implications. Regardless of expertise, both groups faced significant challenges managing the logistics of implementing and maintaining PQC.
I realized PQC isn’t a simple upgrade but one that requires a fundamental shift in system design. My role is to translate that complexity into practical guidance supported by Microchip’s secure product lines so teams can make informed decisions early and build systems that remain secure for decades.
The threat
You mentioned “harvest now, decrypt later.” How long has this threat been known, and how worried should engineers be right now?
The “harvest now, decrypt later” threat has been understood in principle since 1994, when Peter Shor showed that a sufficiently powerful quantum computer could break the mathematical foundations of RSA (Rivest–Shamir–Adleman) and elliptic curve cryptography (ECC).
What has changed in recent years is that this is no longer just a theoretical concern. As National Institute of Standards and Technology (NIST) and the National Security Agency (NSA) have advanced post-quantum standards and migration guidance, it has become a real engineering issue. That urgency is reinforced by the fact that CNSA 2.0 transition timelines are already in effect, so organizations serving government, defense and adjacent markets need to be aligning product plans now, rather than waiting for quantum computers to arrive.
Engineers should not panic, but they should be planning and designing for PQC now. The risk is not that quantum computers are breaking systems today, but that products being designed now will remain in service for decades, locking in cryptographic choices early. If sensitive data is intercepted today, it can be stored and decrypted later once that capability exists. This includes intellectual property, firmware signing keys, device credentials, secure communications, financial and medical records and other proprietary data.
The highest priority concern is for systems that protect long-lived, high-value data or depend on long-term trust, such as servers, firmware update infrastructure, device identity frameworks, encrypted communications, telecommunications, defense systems and other critical infrastructures. For those engineers, the right response is not fear but early design planning: identify where vulnerable public-key cryptography is used, assess how long the protected data must remain secure and begin building in post-quantum support before deployment constraints make the transition far more difficult.
How close are quantum computers to breaking RSA and elliptic curve cryptography? Does the timeline even matter, given the harvest threat?
Quantum computers do not yet practically break RSA or elliptic curve cryptography (ECC), but we know mathematically that they will once sufficiently powerful quantum computers exist. These algorithms are secure today because classical computers would require an infeasible amount of time to solve them. Quantum computing changes this, as algorithms like Shor’s dramatically reduce that effort and make currently impractical attacks feasible. By contrast, symmetric cryptography such as AES or SHA is affected differently and can maintain security with increased key sizes.
The timeline still matters because while the “harvest now, decrypt later” threat is already active, the exposure window continues to grow. A timely transition to PQC directly limits how much new data can be harvested and reduces future risk. It also ensures that newly deployed systems are not vulnerable from the start.
In other words, the longer organizations delay, the more data is exposed and the more systems enter long lifecycles already at risk. A faster transition shrinks that window and reduces the eventual impact.
The timeline therefore matters not just for security, but for market access. As requirements like CNSA 2.0 become embedded in procurement processes, organizations that delay adoption risk being excluded from government, defense and adjacent supply chains.
Who are the primary actors harvesting encrypted data today, and what kinds of systems or data are most at risk?
A range of actors could collect encrypted data, whether opportunistically or deliberately. The key point is that harvesting encrypted traffic is not especially complex if access to communication paths or stored encrypted data already exists.
The greatest risk is to systems that carry or protect long-lived, high-value information such as servers, data centers, cloud platforms, telecommunications systems, defense infrastructure and other critical environments. In that sense, the larger concern is less about identifying a single type of actor and more about understanding which data may still be sensitive years from now.
The transition
CNSA 2.0 is now required for anything entering a U.S. government facility. How many engineers in the field are even aware of that, and what are the real consequences of missing it?
Awareness is growing, but it is still uneven across the broader engineering community. Teams that work directly in security, defense or government-facing programs are generally paying close attention to CNSA 2.0 and the post-quantum transition. Outside of those groups, however, many engineers still view it as a future issue rather than a current design requirement.
That is where the risk lies. CNSA 2.0 is already shaping procurement and design expectations, so missing it directly impacts whether products can be deployed, qualified and sold into key markets. In practice, this can mean losing eligibility for government and defense contracts, being excluded from critical supply chains that inherit these requirements and incurring costly redesigns late in the product cycle when compliance is enforced.
There are also broader implications. Systems that are not transitioned to post-quantum cryptography remain exposed to long-term threats such as “harvest now, decrypt later,” and organizations may face increased liability if sensitive data is later compromised due to outdated cryptography.
The real consequence is that post-quantum readiness is becoming a factor in long-term product viability. Engineers who account for it early have time to make the right architectural decisions. Those who wait may find that retrofitting security, validating new implementations and meeting procurement timelines is far more complex and costly than upfront planning.
What does a realistic migration path look like for a company still running RSA or ECC across its product line? Where do you even start?
Companies should focus on starting early and designing for flexibility. A realistic migration starts with building a clear cryptographic inventory. Companies need to identify where RSA or ECC is used across the product line, such as firmware signing, secure boot, device authentication, key exchange and encrypted communications, and map those uses against product lifecycles, security requirements and transition timelines such as CNSA 2.0 and NIST SP 800-193.
From there, organizations should adopt a phased transition rather than attempt full replacement. Due to system complexity, migration requires careful architectural planning to maintain interoperability and long-term maintainability. This phased approach inherently leads to a hybrid model, to maintain compatibility while transitioning to new cryptographic foundations. This allows for testing, validation and incremental rollout without disrupting existing systems, while also reducing migration risk
PQC adoption introduces new design considerations, including larger key sizes, performance impacts and potential exposure to side-channel and fault injection attacks, all of which must be addressed at the implementation level.
Overall, migration is a multi-year effort driven by emerging standards and mandates. Most organizations will operate in a hybrid state for an extended period, as this enables compatibility with existing infrastructure while transitioning to quantum-resistant algorithms. This hybrid model is not temporary but is a necessary and dominant phase of a long-term transition that, for many systems, can take a decade or more depending on complexity.
The technology
You described the new PQC algorithms as matrix-based rather than factoring-based. Can you explain in accessible terms why that makes them quantum-resistant?
Traditional cryptography like RSA and ECC relies on mathematical problems such as factoring and discrete logarithms that are extremely difficult for classical computers but efficiently solvable by quantum computers using algorithms like Shor’s.
Post‑quantum cryptography is built on different classes of problems, many of which are lattice‑based. These involve large matrices that represent points in very high‑dimensional spaces, where the security comes from finding a hidden structure that is obscured by noise across many dimensions.
What makes these problems quantum‑resistant is that, unlike factoring, there are no known quantum algorithms that provide a significant speedup for solving them. Even quantum computers must rely on approaches similar to classical ones, which remain computationally infeasible at secure parameter sizes.
In simple terms, post‑quantum cryptography isn’t unbreakable, but the problems it relies on don’t have known shortcuts for classical or quantum making them significantly more resistant to future attacks.
You made a strong point that hardware-level implementation is more secure than software-only approaches. Can you walk through exactly why, from an attacker’s perspective?
Post-quantum cryptography needs to be implemented across both software and hardware, but security is built as a chain of trust and hardware forms the foundation of that chain.
Software security assumes that the underlying hardware is trustworthy. If an attacker can compromise or clone the hardware identity of a device, they can bypass software protection entirely.
From an attacker’s perspective, targeting hardware can provide deeper and more persistent access. During early stages like system boot, software protections are not yet active, leaving firmware vulnerable.
That’s why establishing a secure hardware root of trust is essential. It ensures that everything built on top of it (firmware, software and communications) can be trusted.
The new algorithms require larger key sizes and more memory. What are the real-world design implications for constrained embedded systems?
PQC algorithms require larger key sizes and more memory than traditional cryptography, which directly impacts memory footprint, processing performance and power consumption. In constrained embedded systems, where resources are tightly optimized, these changes can significantly affect system design. Beyond resource constraints, many embedded systems are designed for lifecycles measured in decades, making cryptographic decisions difficult to revise after deployment. PQC also introduces added operational complexity, including managing algorithm updates, maintaining SBOMs and ensuring flexibility without introducing new vulnerabilities.
One effective approach to managing this complexity is to offload cryptographic operations to a dedicated hardware root of trust controller. By isolating PQC functions in a standalone security device, engineers can reduce the burden on the main processor, simplify software integration and minimize the risk of system-wide vulnerabilities.
Solutions like Microchip’s TS1800 Platform Root of Trust controller and the TS50x secure boot controller follow this model by containing cryptographic operations within a dedicated, purpose-built device. This isolation helps decouple PQC implementation from the broader system, reducing exposure to software bugs in the main chipset, simplifying updates and providing a more controlled path to address future vulnerabilities as standards and requirements evolve.
The bigger picture
Some of the NIST-selected algorithms have already attracted scrutiny, CRYSTALS-Kyber had a side-channel paper, for instance. How confident are you in the current suite, and how should the industry think about crypto agility going forward?
Effective security doesn’t aim for perfection but aims to stay ahead. Post‑quantum algorithms are built on strong mathematical foundations, but they are not immune to future discoveries. We’ve seen this with RSA and ECC, where side‑channel vulnerabilities emerged despite strong underlying math.
That’s why crypto agility is critical. It may mean supporting multiple algorithms or enabling secure reprogramming so systems can adapt as standards evolve and vulnerabilities are discovered.
What’s your honest assessment of where the industry will be in three years? Are we going to get there in time, or are we heading toward a long tail of vulnerable legacy devices?
In three years, many early adopters will be nearing a transition to primarily using post‑quantum cryptography, particularly in applications aligned with CNSA 2.0 timelines. Other areas will still be in hybrid or transitional phases, where PQC is supported but not yet used exclusively.
There will likely still be a long tail of vulnerable legacy systems. Some organizations will intend to transition but fall behind published timelines due to integration complexity, verification requirements or resource constraints. Others will be slower to adopt altogether, either because their systems were not designed to support PQC or because the data or assets being protected do not justify the added complexity and cost.
This is expected. Security standards aim to deliver protection rapidly, but real‑world design limitations and development cycles influence how quickly adoption can occur. At the same time, awareness is increasing and regulatory pressure is accelerating progress. The industry is moving in the right direction, but timelines remain tight and the systems being designed today will determine how secure we are in the quantum era.
Editor’s note:
To truly grasp the mechanics of quantum-resistant security, I think there is no better resource than Brette’s full technical deep dive.