Enterprise Security in 2035

2035 as a scenario, not a forecast

The title “Enterprise Security in 2035” should not be read as a claim that one particular security architecture will exist in that year. The available evidence supports a set of pressures and decisions, not a single deterministic outcome. Quantum computing remains an open technical question: advanced quantum computers are considered a strong possibility, but researchers must overcome major hurdles, and it is not known exactly when—or even whether—quantum computers will break present-day encryption. Estimates for a cryptographically relevant quantum computer range from a few years to a few decades. [C1]1

A useful 2035 scenario therefore asks what enterprises must be able to do under several possible conditions: complete or nearly complete migration away from quantum-vulnerable algorithms; operate mixed traditional and post-quantum populations during a prolonged transition; respond to weaknesses discovered in post-quantum implementations; and govern AI systems whose security and resilience guidance is still developing. These are evidence-based planning conditions, whereas statements about the exact technologies, attack rates, or organizational structures of 2035 would be speculation. C413

The technical baseline enterprises carry into 2035

Much of today’s public-key cryptography relies on integer factorization or discrete logarithms over finite fields or elliptic curves. RFC 9794 states that these mathematical problems, and therefore algorithms based on them, would be vulnerable to Shor’s algorithm on a sufficiently large general-purpose cryptographically relevant quantum computer. The same document emphasizes that current predictions vary on when, or if, such a machine will exist. [C2]2

The exposure is not limited to data encrypted at the moment a quantum computer becomes available. An adversary may capture encrypted information now and retain it for possible future decryption; this is commonly described as “harvest now, decrypt later.” Long-lived secrets are particularly relevant to this scenario. Products expected to remain in use for many years may also be exposed if their signing algorithms cannot be updated or replaced during their operational lifetime. C31

The post-quantum response is not simply a switch in one algorithm. It can affect protocols, certificates, key establishment, signatures, products, services, hardware, software, suppliers, operational procedures, and records of data sensitivity and retention. NIST’s migration guidance says organizations should identify where vulnerable algorithms are used and plan to replace or update them; it also says cybersecurity products, services, and protocols will need updates. [C6]4

The current standards baseline is more concrete than the future computing threat. NIST released three principal post-quantum standards in August 2024: FIPS 203 for ML-KEM, a module-lattice-based key-encapsulation mechanism; FIPS 204 for ML-DSA, a module-lattice-based digital signature; and FIPS 205 for SLH-DSA, a stateless hash-based digital signature. NIST expects ML-KEM, ML-DSA, and SLH-DSA to provide the foundation for most deployments, while continuing to evaluate additional algorithms and candidates. C74

Credible drivers and dependencies

The first driver is the combination of long information lifetimes and slow technology replacement. NIST notes that integrating a newly standardized algorithm into products and services has historically taken 10 to 20 years. That duration makes migration a present governance issue even when the date of a cryptographically relevant quantum computer is unknown. The relevant question is not only “When will the machine exist?” but also “How long must this data, device, certificate, or signature remain trustworthy?” [C3]1

The second driver is standard and ecosystem transition. A large enterprise may not be able to update all clients at once. ETSI describes mixed populations in which traditional clients understand only traditional algorithms while post-quantum-aware clients can understand both. Hybrid approaches may therefore be used for backwards compatibility and gradual migration, but hybrid interoperability is not automatically the same as hybrid security. C95

The third driver is assurance. ETSI records concerns about the maturity of cryptanalysis for some post-quantum algorithms and about implementation confidence. Post-quantum algorithms may be more complicated than traditional algorithms, implementation mistakes can be difficult to detect, and effective protection against side-channel attacks is still developing. A migration program must consequently evaluate implementation quality, not merely algorithm labels. [C11]5

The fourth driver is AI adoption and exposure. NIST identifies confidentiality, integrity, and availability risks in AI systems and their training and output data, together with security risks in underlying software and hardware. It also says existing frameworks and guidance do not comprehensively address every AI concern, including evasion, model extraction, membership inference, availability, complex attack surfaces, and other abuses. [C12]3

These drivers are dependent on enterprise governance. NIST CSF 2.0 places cybersecurity strategy, expectations, and policy within the Govern function and connects cybersecurity risk management to broader enterprise risk management. Its Identify function requires understanding assets, suppliers, and related cybersecurity risks so that effort can be prioritized consistently with mission needs. [C13]6

Alternative outcomes for 2035

A first plausible outcome is an orderly post-quantum transition. In this scenario, enterprises have inventoried cryptographic use, prioritized long-lived and high-impact information, updated major protocols and products, and established repeatable certificate and key rotation. Traditional and post-quantum components may coexist for a period, with the organization testing whether each construction provides the intended security and interoperability properties. This is an inference from the documented migration and hybridization requirements, not a prediction that all enterprises will succeed. C645

A second outcome is uneven migration. Large or modernized environments may deploy post-quantum standards while legacy systems, suppliers, embedded devices, or external clients continue to require traditional algorithms. The resulting risk is not necessarily visible in a central cryptographic policy: it may reside in a certificate chain, an unreplaceable product, an undocumented dependency, or a partner connection. RFC 9794 describes multiple forms of post-quantum/traditional certificate chains and warns that mixed-chain security properties require case-by-case analysis. [C14]2

A third outcome is a security reset caused by an implementation or algorithm problem rather than by a quantum breakthrough. ETSI’s discussion of attacks against several candidates during the NIST standardization process, together with its warning about implementation complexity and side channels, supports planning for replacement, rollback, and alternative candidates. NIST also identifies ongoing standardization of additional algorithms, including Falcon and HQC, which indicates that the post-quantum ecosystem remains capable of evolving. C1145

A fourth outcome is that AI changes defensive and offensive operations faster than governance adapts. NIST describes AI as having the potential to provide defenders with new tools while also enhancing the capabilities of attackers targeting information technology and operational technology. In this outcome, enterprise security depends on ordinary software and data security controls plus explicit processes for AI-specific risks, evaluation, monitoring, and resilience. [C15]3

Decision signals to monitor

Enterprises should monitor signals that change prioritization rather than attempting to predict a single breakthrough date. The most actionable signals are changes in standards, product support, protocol interoperability, supplier commitments, certificate and key-management capabilities, test results, and the organization’s own discovery of vulnerable or non-updatable systems. NIST’s stated migration direction includes deprecating and ultimately removing quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier. [C6]4

• The percentage of applications, devices, services, certificates, and supplier connections with a known cryptographic inventory.
• The number and business criticality of systems using quantum-vulnerable key establishment or signatures.
• The retention period and required trust lifetime for sensitive data, signed records, software, and devices.
• Whether each migration candidate supports standards-based post-quantum algorithms, controlled hybrid operation, or neither.
• Evidence that a proposed hybrid construction provides the intended security property rather than only backwards compatibility.
• Availability of tested implementation updates, side-channel protections, certificate-chain support, and rollback procedures.
• AI system inventories, documented data flows, security evaluations, and ownership for risks that existing frameworks may not fully cover.

Actions enterprises can take now

Begin with governance and discovery rather than a technology-only procurement exercise. NIST CSF 2.0 describes organizational profiles that can be scoped to an entire organization or to a particular system or threat. Preparing a profile involves collecting policies, risk priorities, resources, enterprise risk profiles, business impact analysis registers, requirements, practices, tools, and work roles; comparing current and target profiles then supports an action plan. [C16]6

1. Assign executive ownership for cryptographic transition and connect it to enterprise risk management, legal, regulatory, contractual, privacy, and business-impact priorities.
2. Create and maintain a cryptographic inventory covering algorithms, protocols, certificates, keys, signing, encryption, libraries, applications, devices, suppliers, and data stores. Record whether each component can be updated or replaced.
3. Classify information and trust relationships by required confidentiality, integrity, availability, retention, and operational lifetime. Prioritize long-lived sensitive data and products that cannot be updated or replaced.
4. Map vulnerable uses to business services and suppliers. Treat unknown cryptographic dependencies as explicit uncertainty rather than assuming that a vendor or platform has solved the problem.
5. Build a target profile for post-quantum migration. Use the available NIST standards as the current foundation while tracking additional standardization and product support.
6. Test ML-KEM, ML-DSA, and SLH-DSA in representative environments, measuring interoperability, performance, certificate handling, operational procedures, and failure behavior.
7. Where hybrid schemes are considered, document whether the goal is hybrid security, hybrid interoperability, or both. Avoid ad hoc constructions; ETSI warns that they can introduce weaknesses and that the two goals do not necessarily provide the same guarantees.
8. Create migration waves, with early treatment for high-risk systems and systems with long replacement cycles. Include supplier contracts, acceptance tests, incident response, rollback, and key and certificate rotation.
9. Extend the same governance discipline to AI systems: inventory models and data, assign owners, assess confidentiality, integrity, availability, software, hardware, and AI-specific risks, and revisit assessments as guidance and attacks evolve.
10. Define measurable decision gates and rehearse them. A useful gate is not simply “post-quantum enabled,” but “known dependency, tested implementation, approved security property, operationally supportable, and recoverable if assumptions change.”

The objective is crypto-agility in the practical sense of being able to understand, test, update, replace, and recover from cryptographic change. The cited evidence does not establish a universal architecture or promise that any one algorithm, hybrid construction, vendor product, or AI control will remain suitable through 2035. It does support a disciplined program that makes dependencies visible, prioritizes based on impact and lifetime, and keeps technical decisions revisable. C6[C11]43

Uncertainty and limitations

The evidence does not establish when a cryptographically relevant quantum computer will exist, whether it will be built, how capable it will be, or which enterprise systems would be attacked first. It also does not prove that every post-quantum implementation will be secure, interoperable, performant, or easy to operate. Those unknowns are reasons to preserve options and test assumptions, not reasons to treat the scenario as a guaranteed forecast. C1[C11]135

The AI evidence has a similar limitation. NIST describes security and resilience as active research areas in which challenges and potential solutions are changing rapidly. The AI RMF is intended for voluntary use, and NIST released a generative AI profile on July 26, 2024; the cited material therefore supports risk-management planning but not a claim that a complete, settled AI security standard for 2035 already exists. C123

Conclusion

Enterprise security in 2035 cannot be responsibly summarized as “quantum-safe” or “AI-secure” by a particular date. The evidence instead supports a preparedness model: recognize the uncertainty of quantum computing, act on the present risk to long-lived data, migrate from vulnerable algorithms using a controlled and standards-aware process, scrutinize hybrid designs, and govern AI as a changing security and resilience concern. Enterprises that begin with inventories, business impact, target profiles, supplier visibility, testing, and reversible decisions will be better positioned across multiple futures—not because the future is known, but because their security program can adapt when evidence changes. C3C131463