“Post-Quantum Security Is Not a Library It’s a Language Problem”

Quantum computing is no longer a distant threat. The buzz around post-quantum (PQ) cryptography is growing rapidly, especially on Security Twitter, Medium, and among CISOs. Yet, much of the current discussion feels shallow or driven by vendors pushing quick fixes. The reality is more complex. You cannot retrofit post-quantum security into systems that never modeled trust. This post explains why post-quantum security is not just about swapping cryptographic libraries but about rethinking how systems express and enforce trust through language and architecture.

Post-quantum security requires architectural clarity, not just new libraries

Why Post-Quantum Flags Aren’t Enough

Many organizations believe that simply adding PQ cryptography flags or switching to PQ algorithms will solve the problem. This approach misses the point. PQ flags are often just checkboxes in software or hardware configurations. They do not address the deeper question of how trust is modeled and enforced in a system.

Trust is not a binary setting. It involves policies, assumptions and guarantees that must be clearly defined and embedded in system design. Without this, PQ algorithms become a band-aid on a broken foundation. For example, if a system assumes that keys are never exposed but does not enforce this through policy or architecture, switching to PQ keys will not prevent compromise.

PQ flags can help identify where PQ algorithms are used, but they do not ensure that the system’s trust model aligns with the new cryptographic assumptions. This gap leads to vulnerabilities and false confidence.

Why Policy-Before-Execution Matters

The core challenge is that trust must be modeled before execution, not after. Systems need a policy language that defines what is trusted, how trust is established, and what guarantees are required. This policy must be enforced at runtime.

Policy-before-execution means:

• Defining trust boundaries explicitly

• Specifying which components can access or modify sensitive data

• Enforcing cryptographic guarantees consistently across the system

• Handling key lifecycle and revocation with clear rules

  
  

Without this, post-quantum algorithms are just new tools used in old ways. The system’s behavior remains unpredictable and insecure.

Consider a system that encrypts data with a PQ algorithm but does not control who can decrypt or how keys are managed. The policy is missing, so the system remains vulnerable to insider threats or misconfigurations.

How 11/11 Handles This Cleanly

The 11/11 project offers a fresh approach by treating post-quantum security as a language problem rather than a library upgrade. It introduces a clear, formal language for expressing trust policies that integrate PQ cryptography naturally.

Key features of 11/11 include:

• Explicit trust modeling: Trust relationships are defined in a structured language, making assumptions clear and auditable.

• Policy enforcement: The system enforces policies at runtime, preventing unauthorized actions even if cryptographic primitives change.

• Modular design: Cryptographic algorithms, including PQ ones, are components plugged into the trust language, not hardcoded.

• Future-proofing: Because trust is expressed in language, new cryptographic methods can be integrated without redesigning the entire system.

  
  

For example, 11/11 allows a policy to specify that only certain services can decrypt data and only if they present valid PQ proofs. This policy is enforced automatically, reducing human error and increasing security.

Trust policies expressed in a formal language enable clear enforcement of post-quantum security

Where Post-Quantum Security Trends

The conversation around PQ security is vibrant in several communities:

• Security Twitter/X: Researchers and practitioners share insights, critiques and updates on PQ cryptography and system design.

• Medium articles: Thought leaders publish accessible explanations and case studies, often highlighting gaps in current approaches.

• CISOs and security teams: Organizations evaluate PQ readiness, balancing hype with practical implementation challenges.

  
  

Despite this interest, many discussions focus on cryptographic algorithms alone. The architectural and policy aspects receive less attention, even though they are critical for real security.

Practical Steps for Organizations

To move beyond shallow PQ adoption, organizations should:

• Assess trust models: Review how trust is currently defined and enforced in systems.

• Adopt policy languages: Explore tools and frameworks that allow expressing trust policies explicitly.

• Integrate PQ cryptography thoughtfully: Treat PQ algorithms as components within a broader trust framework.

• Train teams: Educate developers and security staff on the importance of policy-before-execution.

• Monitor and audit: Continuously verify that policies are enforced and cryptographic assumptions hold.

  
  

These steps help avoid the trap of retrofitting PQ security onto systems that never modeled trust properly.