Government & Defense-Adjacent Systems — Field Guide

Important. VellumGuard is not a certified compliance platform. It does not satisfy NIST SP 800-171, CMMC, or any defense contract security requirement on its own. Do not process CUI (Controlled Unclassified Information) or regulated production data through VellumGuard without a separate written agreement.

The problem

CNSA 2.0 (Commercial National Security Algorithm Suite, version 2) sets a 2035 migration deadline for national security systems. For organizations with defense or federal customers, post-quantum readiness is increasingly a procurement and planning question — not a future consideration.

Large migration programs take years. Infrastructure changes, protocol updates, hardware replacements — these cannot happen overnight. But application-layer encryption can start now. Starting now builds practical experience, creates auditable evidence of post-quantum readiness, and reduces the scope of the larger migration when it arrives.

The specific threat model is "harvest now, decrypt later": adversaries collecting government or defense-adjacent data today may be betting on the ability to decrypt it when capable quantum hardware becomes available. For data with a long sensitivity window, the encryption applied at creation time is the protection you will be relying on.

Example workflow

A defense contractor maintains an internal coordination portal where engineers share project analysis outputs, deliverable reviews, and partner communications. They want to encrypt those payloads at the application layer using NIST-standardized post-quantum algorithms, separate access by project workspace, and generate auditable key lifecycle records that show post-quantum encryption was in use.

After deploying VellumGuard, they can document: which NIST algorithms are used, which keys protect which workspaces, when keys were promoted or rotated, and who has access to each workspace's key material. That documentation supports post-quantum readiness discussions with customers, auditors, and procurement officers.

Where VellumGuard fits

Hybrid post-quantum encryption at the application layer: X25519 + ML-KEM-768 and Ed25519 + ML-DSA-65
NIST-standardized algorithms only — FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA)
Workspace separation and identity-scoped API keys for per-project or per-partner isolation
Audit events for every key operation: promote, rewrap, retire, decrypt
A concrete post-quantum implementation that supports migration planning documentation
Cloud KMS-backed key wrapping: DEKs are wrapped by Google Cloud KMS and never touch disk or logs in plaintext

What teams can test in beta

Encrypting internal application payloads with hybrid post-quantum crypto using test data
Reviewing NIST algorithm choices for security documentation and procurement responses
Running the full key rotation lifecycle: generate, promote, rewrap, retire
Generating audit event logs for key operations to support compliance documentation
Evaluating SDK integration effort for existing Node/TypeScript applications
Walking through how the ciphertext format and algorithm choices align with CNSA 2.0 guidance

What VellumGuard does not replace

VellumGuard handles application-layer encryption and key management. It does not replace or certify compliance with:

NIST SP 800-171 or NIST SP 800-172 (CUI protection requirements)
CMMC practices or assessment requirements (see the CMMC field guide)
Network-layer encryption migration (TLS, VPN, protocol updates)
Endpoint security controls
Identity and access management programs
Defense contract security requirements or DFARS clauses
SIEM, log aggregation, or monitoring programs

No compliance certifications are in place. No formal SLA during beta. Use test or synthetic data unless separately agreed in writing.

Request design partner access

If you are building systems for government or defense-adjacent customers and want to begin post-quantum application-layer encryption in a controlled beta, apply for design partner access.

Apply for access →