Cryptography in an AI-Native World

1. What is established today

“AI-native” is best understood here as an environment in which AI systems and AI-enabled capabilities are embedded in software, data, operational technology, and decision processes. The evidence does not establish one inevitable AI security outcome. It does establish that AI systems have many of the same security requirements as other information systems: confidentiality, integrity, and availability of the system, its training data, and its outputs, together with security of the underlying software and hardware. NIST also describes AI security and resilience as an active research area in which challenges and potential solutions are changing rapidly. This makes a durable baseline more useful than a prediction: govern cryptographic dependencies and system security continuously, while reassessing assumptions as capabilities and threats change.1

The quantum dimension is a separate but connected driver. NIST describes quantum computers as a developing technology that could eventually break defenses protecting confidential electronic information. The field remains in its infancy, major technical hurdles remain, and it is an open question how formidable quantum computers can become. At the same time, advanced quantum computers remain a strong possibility with potentially major consequences for present-day encryption. The appropriate conclusion is neither complacency nor certainty about a date: organizations have a sufficiently material long-term exposure to begin migration planning and implementation now.2

2. Why AI and quantum drivers matter together

AI can amplify both defensive and offensive activity. NIST identifies the prospect that AI technologies could give defenders new tools to address vulnerabilities, while also enhancing the capabilities of actors targeting organizations and individuals through information-technology and operational-technology attacks. Existing guidance does not comprehensively address every AI-specific concern, including evasion, model extraction, membership inference, availability, complex attack surfaces, and other abuses enabled by AI systems. These observations support a cautious inference: cryptographic controls may increasingly be deployed, monitored, and attacked inside systems whose behavior, data flows, and dependencies are difficult to understand completely. That is a reason to improve inventory, assurance, monitoring, and governance—not evidence that AI itself breaks current cryptography.1

Quantum risk creates a different dependency. Traditional public-key encryption may be vulnerable if a sufficiently capable quantum computer is developed. RFC 9794 notes that encrypted information can be stored for later decryption by a future attacker with a cryptographically relevant quantum computer. Long-lived signing algorithms are also exposed when products cannot be updated or replaced during their operational lifetime. Consequently, an enterprise should assess not only whether a quantum computer exists today, but also how long information must remain confidential, how long signatures must remain trustworthy, and how long a system will remain deployed.3

This produces a portfolio problem. Short-lived, replaceable services may have more migration flexibility than embedded devices, archived records, industrial systems, or products with long certificate and signature lifetimes. AI systems add another layer: training data, model artifacts, prompts, outputs, APIs, identity systems, and vendor integrations may all depend on cryptographic mechanisms. The cited evidence does not quantify which of these assets is most exposed in every enterprise, so prioritization must be based on the organization’s own data lifetimes, business impact, dependencies, legal requirements, and replacement constraints.35

3. The post-quantum baseline and its limits

NIST’s post-quantum standardization effort began with an open international evaluation process. NIST reports that it assessed candidate algorithms through multiple rounds of expert analysis, reducing the candidate set over time. The first three finalized post-quantum standards were released in 2024. NIST identifies ML-KEM as a key-encapsulation mechanism and ML-DSA and SLH-DSA as digital-signature standards; it expects these three to provide the foundation for most deployments. NIST is also evaluating additional algorithms, including Falcon and HQC, and is pursuing additional digital-signature schemes that could provide backup or address particular use cases.24

The practical implication is that organizations do not need to wait for an entirely settled ecosystem before beginning. NIST states that the principal standards can and should be put into use now, and its migration material advises organizations to identify vulnerable algorithms and plan to replace or update them. However, “use now” does not mean deploying an algorithm everywhere without engineering analysis. Post-quantum algorithms can have different sizes, performance characteristics, functionality, and implementation considerations. The enterprise must test protocol behavior, certificates, key management, hardware support, application compatibility, operational procedures, and recovery processes in its own environment.42

Confidence also has limits. ETSI notes concerns about the maturity of cryptanalysis for some algorithm families, cites high-profile practical attacks against GeMSS, Rainbow, and SIKE during the NIST standardization project, and explains that confidence in implementations takes time to build. It further notes that post-quantum algorithms can be more complicated than traditional algorithms, implementation mistakes can be difficult to detect, and effective protection against side-channel attacks is still developing. The correct posture is therefore migration with assurance: use standardized and appropriately reviewed components, preserve the ability to update, and treat implementation security as a first-class workstream.6

4. What hybrid cryptography can and cannot do

A hybrid scheme or protocol combines post-quantum and traditional components. ETSI identifies two important motivations: reducing the risk of moving directly away from traditional algorithms while confidence in post-quantum algorithms and implementations develops, and supporting forward compatibility or backwards compatibility during migration. A well-designed hybrid construction can remain secure if at least one component algorithm remains secure, depending on the construction and its security analysis. Hybrid deployment can therefore be a useful transition pattern, especially where interoperability cannot change at once or where sensitive information has a long confidentiality horizon.6

Hybrid is not synonymous with automatically safer. ETSI warns that complexity in protocols, implementations, and key management increases. The security properties of post-quantum algorithms can differ subtly from those of traditional algorithms, and the security guarantee that remains if one component is broken must be analyzed explicitly. Inappropriate hybrid schemes can be less secure than a non-hybrid post-quantum mode. Negotiation must also be protected against downgrade attacks. Requirements may differ for confidentiality and authentication: a long-lived encrypted session may justify one design, while a signature used only to establish a session may require another analysis.6

This distinction matters for AI-native architectures because they frequently cross organizational and protocol boundaries. A service may negotiate transport security, obtain certificates through a public-key infrastructure, call a model provider, store artifacts, and exchange data with older systems. A migration plan should record where hybrid behavior is required for interoperability, where pure post-quantum support is feasible, which negotiation mechanisms are protected from downgrade, and how key and certificate lifetimes align with the confidentiality or authentication objective. These are implementation decisions, not conclusions that can be made from the label “AI-native” alone.6

5. An evidence-led decision framework

The NIST Cybersecurity Framework 2.0 provides a useful governance structure for this scenario. Its Govern function calls for an organization’s cybersecurity risk-management strategy, expectations, and policy to be established, communicated, and monitored. Organizational context includes mission, stakeholders, dependencies, legal, regulatory, and contractual requirements. Risk-management strategy includes priorities, constraints, risk tolerance and appetite statements, and assumptions. These elements help prevent a cryptographic program from becoming an isolated algorithm replacement exercise.5

Create a current profile and a target profile for cryptographic readiness. NIST describes current profiles as characterizing the outcomes an organization currently achieves or is attempting to achieve, and target profiles as desired outcomes selected and prioritized for risk-management objectives. The target should account for anticipated changes such as new requirements, technology adoption, and threat-intelligence trends. For a cryptographic program, the profile can cover algorithm use, key and certificate management, protocol support, updateability, vendor dependencies, sensitive-data lifetimes, signature validation requirements, testing evidence, and recovery capability.5

Then perform a gap analysis and action plan. The CSF profile process calls for gathering policies, risk priorities and resources, enterprise risk profiles, business-impact analysis registers, requirements and standards, practices and tools, and work roles; creating the profile; analyzing gaps between current and target states; and creating an action plan. This process supports scenario analysis because it makes assumptions visible. For example, an enterprise can model an outcome in which quantum progress is slower than expected, one in which migration standards evolve, and one in which a high-value data set is targeted for delayed decryption. The evidence does not assign probabilities to those outcomes; the organization should use impact, time-to-migrate, and reversibility to prioritize them.5

6. Actions enterprises can take now

First, establish ownership and scope. Assign accountable leaders across security, infrastructure, application engineering, data governance, procurement, architecture, and AI governance. Define which business services, AI systems, products, records, and third-party dependencies are in scope. Record mission objectives, stakeholder expectations, regulatory and contractual requirements, risk tolerance, and assumptions. This follows the CSF emphasis on organizational context and risk-management strategy and makes trade-offs visible to decision-makers.5

1. Inventory cryptographic use rather than only cryptographic products. Identify algorithms, protocols, certificates, keys, libraries, modules, signing services, stored ciphertext, trust stores, model and data repositories, vendor-managed services, and embedded or operational technology dependencies.
2. Classify exposure by confidentiality lifetime, signature lifetime, business impact, updateability, replacement lead time, interoperability constraints, and dependence on traditional public-key mechanisms. Mark systems that cannot be updated or replaced easily.
3. Build a current and target profile. Define the required future outcomes, the evidence that would demonstrate them, owners, dependencies, exceptions, and deadlines. Keep uncertainty and assumptions explicit rather than presenting a forecast as fact.
4. Pilot finalized post-quantum standards in representative paths. Test ML-KEM, ML-DSA, and SLH-DSA where their respective key-establishment and signature roles fit, while evaluating performance, message and key sizes, certificate handling, hardware, logging, backup, recovery, and operational support.
5. Evaluate hybrid designs only for a stated purpose. Document the component algorithms, combiner or protocol behavior, downgrade protections, failure assumptions, interoperability mode, and the security property required for confidentiality versus authentication.
6. Engage suppliers. Ask vendors which algorithms and protocols are used, whether inventory and replacement are supported, how updates are delivered, what certificate and key lifetimes apply, and how the supplier will respond to standards or implementation findings.
7. Exercise governance continuously. Monitor standards, implementation assurance, threat intelligence, technology adoption, contractual requirements, and lessons from testing; update the target profile and action plan when signals change.

Second, make reversibility a design requirement. RFC 9794 and ETSI both describe migration and hybrid considerations in terms of component algorithms, protocols, interoperability, and future changes. An enterprise should avoid coupling a critical service to an algorithm, certificate format, vendor, or hardware path that cannot be changed without a full redesign. This does not require claiming that every component is immediately algorithm-agnostic; it requires identifying the coupling, measuring the cost of change, and funding the work before a crisis makes the dependency unavoidable.6

Third, connect cryptographic readiness to AI risk management rather than treating it as a separate compliance checklist. NIST’s AI RMF is intended for voluntary use to improve the incorporation of trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems. It identifies secure and resilient as a primary characteristic of trustworthy AI. A practical enterprise profile can therefore connect AI asset and data-flow governance with cryptographic inventory, access control, software assurance, supplier risk, incident response, and recovery.3

7. Alternative outcomes and decision signals

Several outcomes remain credible on the cited evidence. Quantum computing may progress slowly because major technical hurdles persist; it may eventually become capable enough to threaten traditional cryptography; or migration may be disrupted by implementation weaknesses, interoperability problems, or new cryptanalytic findings. AI may improve defensive capability, increase attacker capability, or do both at once. None of these outcomes is established as the forecast. The robust strategy is to choose actions that reduce exposure across multiple outcomes: inventory, prioritization, tested updates, supplier visibility, and governance are useful even if the timing of quantum progress changes.216

Useful signals include a change in the status of post-quantum standards; new evidence about algorithm or implementation security; availability of tested protocol and hardware support; supplier migration commitments; changes in data-retention or signature requirements; discovery of systems that cannot be updated; new AI deployments that introduce sensitive data flows; and changes in legal, contractual, or stakeholder expectations. The CSF’s adaptive tier describes organizations that adjust practices based on previous and current activities, lessons learned, and predictive indicators. That adaptive behavior is a better operating model than waiting for a single decisive announcement.465

8. Limits of the evidence

The cited sources support a baseline, a migration direction, and governance practices; they do not provide a date for a cryptographically relevant quantum computer, a probability for any alternative outcome, a universal algorithm choice for every use case, or a complete inventory method for every AI architecture. NIST’s AI security material explicitly describes the area as active research and says existing frameworks and guidance do not comprehensively address all AI security concerns. Post-quantum labels also do not guarantee that an algorithm will never be compromised. Enterprise decisions should therefore preserve uncertainty, validate claims in the relevant environment, and avoid representing scenario analysis as prediction.213

Conclusion

Cryptography in an AI-native world is a continuous assurance problem shaped by two different realities: AI systems already carry broad and changing security risks, while sufficiently capable quantum computers remain uncertain but could undermine important traditional public-key protections. The evidence supports action without pretending to know the future. Inventory cryptographic dependencies, prioritize long-lived and hard-to-replace assets, use current and target risk profiles, test the finalized post-quantum standards, and evaluate hybrid schemes with explicit security and downgrade assumptions. Keep the program adaptive: update priorities as standards, implementations, suppliers, AI deployments, requirements, and threat intelligence change.12465