Prove your post-quantum readiness on the scale your customers will use.
Post-Quantum Readiness
FEDLIN builds this for government contractors and critical-infrastructure operators carrying a cryptographic liability without a dedicated cryptography engineer on staff. This is the working guide to that migration: whether the trigger is a federal contract, a utility audit, or a customer security review, where a plan starts, and how the work gets sequenced against dated deadlines. The pressure is already here. Adversaries capture encrypted traffic today and hold it until they can decrypt it, so data that must stay confidential for years is already exposed. Readiness has also become a supply-chain question, measured on a shared scale, the PKI Consortium's PQC Maturity Model.
Post-quantum readiness is one part of FEDLIN's crypto-agility engineering →
Engineered by Jeremiah Coakley, Principal Security Architect
A working guide
The post-quantum migration, from the mandate to the work.
The federal deadlines are set and the inventory is mandated. What follows is how the migration actually goes: the foundation it stands on, what the mandate requires, where a plan starts, and how the work gets sequenced.
1. Foundations: the platform under the algorithms
Before any algorithm changes, the systems underneath have to support them. For federal and CNSA 2.0 systems, that floor is FIPS 140-3 validated cryptography, and CMVP's validation pipeline for the post-quantum algorithms is still catching up to the standards themselves. Everywhere else, the floor is simpler but still uneven: modern TLS stacks can run ML-KEM and ML-DSA at the network edge today, while native support deeper in the stack, a cluster's own certificate infrastructure, for example, is still catching up. Either way, getting there is real engineering work, done before the algorithm swap starts, which is what keeps that swap from turning into a rebuild.
Go deeper: rebuilding for FIPS 140-3 →2. The threat and the mandates
Executive Order 14412 and OMB M-26-15 turned post-quantum from a recommendation into a dated federal requirement: agency migration plans due October 2026, key establishment by the end of 2030, and digital signatures by the end of 2031, with a proposed FAR rule reaching covered contractors. Commercially, PCI DSS 12.3.3 already requires the same cryptographic inventory and viability monitoring, mandatory since March 2025, and the underlying pressure is universal either way: traffic captured today can be decrypted later.
Go deeper: what the federal deadline means for your contracts →3. The transition: where a plan starts, and who owns it
A migration plan does not start with choosing an algorithm. It starts with knowing what cryptography you run and deciding who owns the work, including the parts that live inside vendor products you do not control. The teams that stall are the ones that skip those two steps and reach for the algorithm first.
4. Doing the work: inventory, then algorithm selection
You can't fix encryption you can't see, so the work starts with an inventory of every place your encryption lives (a CBOM, the format assessors expect). Then each item gets the right replacement, with federal and commercial targets held separately, sequenced by what breaks first if you wait. Some of those replacements already run on most infrastructure today.
You can see part of your own posture the way FEDLIN sees its own: run a free scan against your public edge below, the same read we run against ours.
Further reading: Addie LaMarr's Post-Quantum Field Guide is a thorough practitioner reference on the transition.
If you are ready to act on this, here is how engagements work.
How engagements work
Three steps, each a different shape of the same problem.
The free scan reads your public edge. The assessment inventories what runs inside your boundary, a separate measurement priced for what it covers. The program keeps the evidence current for as long as your obligation runs: the federal timeline to 2035, or PCI's 12.3.3 review cycle.
Free · Public-edge scan
See where you stand today
Your externally-visible cryptographic posture, graded in a minute. No signup, and nothing runs inside your network. It reads the certificate your server already broadcasts.
Run the scan →Paid · Readiness assessment
Inventory what the scan cannot reach
The encryption a public scan can't see, inventoried inside your boundary, with a replacement roadmap you can hand to an assessor. $5,000 per production environment (including a PCI DSS 12.3.3 CDE), declared or measured by access. Federal work is delivered through your prime or integrator. A short scoping call and a Statement of Work confirm exact scope before work begins.
See the assessment →Ongoing · PQC Program
Keep the evidence alive to 2035
Quarterly re-inventory, roadmap maintenance, and a set advisory allotment with FEDLIN as the named owner of your migration. Bounded and priced as a subscription.
See the program →A supply-chain question
Your customers ask where you stand on a shared scale.
Post-quantum migration stops at the supplier boundary: your readiness depends on the products and vendors that run your business. So customer reviews increasingly ask for your position on a shared scale, the PKI Consortium's PQC Maturity Model (six cumulative levels, 0 to 5). A roadmap counts once the evidence backs it.
FEDLIN builds to the model your assessors use, so your readiness maps directly to what a customer review asks for.
What do you run?
EO 14412 & OMB M-26-15: the deadlines are set
On June 22, 2026, Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks," set the federal timeline: high-value assets and high-impact systems transition to PQC for key establishment by December 31, 2030 and for digital signatures by December 31, 2031. The order directs the FAR Council to propose a rule, within 180 days, requiring covered contractors to comply by the end of 2030 with NIST's FIPS.
OMB M-26-15 (June 2026) turned the order into a five-phase migration to 2035. Phase 1 is the cryptographic inventory, and agency migration plans are due to OMB and the National Cyber Director in October 2026, aligned to NIST's draft IR 8547 timeline. FIPS 140-2 module validations moved to the Historical List on September 21, 2026.
One day later, on June 23, the Department of War issued its own Post-Quantum Cryptography Strategy, the first department-wide plan, putting defense systems on the same 2030/2031 clock.
The deadlines are cited, dated, and flowing to contractors. The inventory is mandated, and it starts with knowing exactly where you stand.
Audience
Who This Is For
Federal contractors & primes
EO 14412 directs a FAR amendment, still at the proposed stage, that would pull covered contractors to NIST's post-quantum FIPS by 2030. For products that deploy into national security systems, NSA's CNSA 2.0 sets the required algorithms: ML-KEM-1024, ML-DSA-87, and LMS/XMSS for firmware signing. The assessment maps to that NSS suite specifically, for unclassified environments, in your own systems.
Encryption on systems you can't replace on schedule
Substations, control networks, and vendor appliances often can't run modern cipher suites, and replacing them follows capital cycles measured in decades. The inventory covers the encryption protecting BES Cyber System Information in transit and at rest (NERC CIP-011-3). Every finding the hardware can't support gets a documented treatment: mitigate, or accept with compensating controls an auditor can follow.
See critical infrastructure →FinTech, payments & signed records
Platforms handling payments or any record with a multi-year confidentiality horizon carry harvest-now-decrypt-later exposure; signed records that must stay verifiable for years face a parallel long-term forgery risk. In payments, PCI DSS v4.0.1 already requires a documented inventory of your cipher suites and protocols with active monitoring for obsolescence (Requirement 12.3.3, in force since March 2025). That inventory is the first step a post-quantum migration builds on. Cryptographic longevity is now a question from enterprise buyers, auditors, and regulators, and a CBOM plus a sequenced roadmap is the defensible answer.
The cryptographic liability you can't staff for
You ship a product without a cryptography team on staff. Then a customer security review, a PCI questionnaire, or a contractual obligation asks for a cryptographic inventory and a documented response plan, and there's no one to own it. That's cryptographic debt in practice, and it's exactly what this assessment hands you directly: the inventory, the roadmap, and the artifact that answers the question, without a hire.
Engagements
PQC Readiness, priced per scope boundary.
A cryptographic inventory, viability monitoring, and a documented response plan, per boundary.
One boundary is one production environment, and most engagements are a single boundary. It is $5,000 per production environment the first year (including a PCI DSS 12.3.3 CDE), then $2,000 for the annual re-review. Each boundary is assessed declared (no-touch) or measured (in-boundary), sized from the free scan and a short declaration. Federal work is delivered through your prime or integrator: see how we work behind primes and integrators, or hand your contracting team our Capability Statement. As with every FEDLIN engagement, a short scoping call and a Statement of Work confirm exact scope before work begins.
Buying through a prime or integrator?Declared posture
$5,000 per production environment
First year, then $2,000 for the annual re-review (including a PCI DSS 12.3.3 CDE). Federal work is delivered through your prime or integrator. Scoped on a call and set in a Statement of Work before work begins.
For organizations that run almost nothing directly
You declare your systems, providers, and service boundaries. FEDLIN maps the cryptographic exposure on your side of each provider relationship and produces the provider inquiry set your team submits to the next layer of the supply chain.
Nothing is installed in your environment. No configuration is changed. No tooling runs inside your boundary. For federal subcontractors, it produces the inherited-control register your agency customer's inventory draws on.
Each scope boundary is captured from a declaration template your team completes in a single intake session. Additional boundaries are quoted per boundary. Estates with production infrastructure use the measured posture below.
Best for
- → Government contractors and federal subcontractors whose systems run mostly on provider-hosted infrastructure
- → Organizations that inherit most of their cryptography from providers
- → Software or cloud companies with a contractual, customer-questionnaire, or PCI cryptographic obligation and no in-house cryptography engineer
- → PCI-scoped commercial teams whose CDE is provider-hosted
What this assessment produces
- →Inherited-control register: assets declared by your team, attributed to provider or internal responsibility, each flagged crypto-agile or constrained (hardcoded firmware, vendor appliance, legacy device)
- →Provider inquiry set: the questions your providers must answer to complete the OMB M-26-15 supply-chain trace
- →Phase 1 submission narrative for the inventory sections (methodology, prioritization) your ISSO folds into the agency migration plan
- →CNSA 2.0 migration roadmap: assets mapped to NSS or commercial target, sequenced by break-priority
- →NIST 800-53 crosswalk mapping each declared asset to the control family it affects (CM-8, SC-8, SC-12, SC-13, SC-17, SC-28)
- →Detached SLH-DSA (FIPS 205) attestation
Measured posture
$5,000 per production environment
First year, then $2,000 for the annual re-review (including a PCI CDE). Federal work is delivered through your prime or integrator. Sized from the free scan.
For organizations with production infrastructure
One production system or a full authorization boundary, live runtime cryptography (TLS negotiations, certificate algorithm chains, key stores, SSH host keys) captured alongside source and container inventory. This is where the real exposure lives: the algorithms negotiated in production, beyond the ones declared in the code.
Runs entirely inside your boundary, an in-boundary container with no egress. The cryptographic map, itself a sensitive artifact, never leaves the tenant. For federal and CUI-bearing systems, this is the delivery posture.
Runs where you run: OpenShift and Kubernetes (EKS, GKE, AKS, k3s), Azure, AWS, and GCP tenants, and Windows hosts with AD CS alongside Linux. The classification ruleset is scrim-validated on OpenShift and on Windows Server with AD CS.
Best for
- → Federal agencies and contractors under EO 14412 with production systems in scope
- → Organizations with TLS termination, certificate infrastructure, and key stores in-house
- → Teams that need a NIST 800-53 crosswalk (federal) or a defensible PCI 12.3.3 audit trail (commercial) alongside the inventory
- → Software or cloud companies, including PCI-scoped commercial teams, running their own production infrastructure with a customer-questionnaire or PCI cryptographic obligation and no in-house cryptography engineer
What this assessment covers
- →Live TLS: cipher suites, protocol versions, and certificate algorithm chains across all in-scope endpoints
- →Certificate infrastructure: algorithm, key length, expiry, and trust chain for every cert in scope
- →Key stores: key material algorithm and length across HSMs, secrets managers, and config. Reads public object names only; no private key or secret value is read, and no write access is required
- →Source and container inventory: full static analysis included
- →NIST 800-53 crosswalk: every finding mapped to the control family it affects
- →FEDLIN Cryptographic Readiness Report: an executive scorecard you can hand to a customer or assessor (readiness score, letter grade, exposure counts, and which data could be recorded now and decrypted later), a sequenced roadmap with an owner on every item, the full machine-readable inventory (CycloneDX CBOM), and a signed attestation the recipient can verify
The register answers the inventory your agency customer asks for.
The inherited-control register and provider inquiry set answer the inventory your agency customer asks for, produced inside your boundary, ahead of the FAR rule, with nothing leaving the boundary to authorize. Delivered through your prime or integrator as scoped, fixed-price work: how we work behind primes · Capability Statement.
The Report opens the migration
The same Report answers the gate in front of you: a customer security questionnaire, a cyber insurance audit, or the 100-day TLS-certificate cap arriving March 15, 2027 (then 47 days by 2029). From there it routes into the Security Program that implements the roadmap and owns crypto-agility as the standards move.
Ready to build the migration, beyond the assessment?
FEDLIN implements what the assessment surfaces: the application-layer post-quantum signing and the rest of the crypto-agility work.
The artifact
It starts with knowing where your encryption lives
Every migration begins with knowing what you have: where the vulnerable algorithms live, at which layer, and what they protect. Where FEDLIN measures your systems, that inventory comes in machine-readable form (a CBOM) that drops straight into your evidence. The declaration-based Boundary tier delivers the same picture as the inherited-control register. What a CBOM contains and how it's used →
An inventory your tools can read
Delivered as a Cryptographic Bill of Materials in the ECMA-424 (CycloneDX) standard: machine-readable, comparable from one release to the next, and portable straight into your GRC evidence.
The filing you already owe
OMB M-26-15 makes the cryptographic inventory the Phase 1 deliverable of the federal PQC migration, with agency plans due October 2026. The CBOM is that artifact: the inventory is the Phase 1 deliverable; the migration plan submitted to OMB carries additional required elements, and the Report supplies the inventory methodology, prioritization, and third-party coordination inputs for those. And EO 14412 directs CISA and NIST to publish the minimum elements for a CBOM by ~March 2027: federal guidance naming the exact artifact this assessment produces.
What it covers, stated plainly
The CBOM covers the cryptography the toolkit resolves across the defined scope: classical algorithms (RSA, ECDSA, DSA), deployed post-quantum and EdDSA certificates, live TLS and SSH posture, key stores, and dependency-graph cryptography. Surfaces it does not reach (IPsec/VPN, Kerberos, and protocol-embedded code-signing) are named explicitly as out of scope, and heuristic findings carry a confidence level. It's an inventory you can defend, clear about what it covers and what it doesn't.
The decision layer
Raw inventory is a commodity. The CNSA 2.0 judgment is the product.
Open-source tooling (IBM CBOMkit, CycloneDX) produces the raw inventory. FEDLIN's product is the decision layer on top: classifying each asset against the approved suite and holding two target paths distinct, because the wrong target is worse than no target.
CNSA 2.0, the NSS suite
For national-security systems and the defense supply chain: ML-KEM-1024 for key establishment, ML-DSA-87 for general signatures, and LMS / XMSS for firmware and software signing, the stateful hash-based schemes CNSA 2.0 designates for that role. This path stands distinct from the commercial one. The NSS clock is nearer than 2030: under CNSA 2.0, new NSS acquisitions must be quantum-resistant by default from January 1, 2027, so the burden shifts to design and procurement now.
FIPS 203/204/205
For commercial and regulated-industry systems: ML-KEM (FIPS 203) for key establishment and, where a signature has to remain valid for a decade or more, SLH-DSA (FIPS 205): stateless hash-based signing that doesn't rest on lattice assumptions. Each asset is ranked by break-priority and data longevity, then sequenced.
The algorithm targets come from the public CNSA 2.0 standard. What FEDLIN brings is the judgment that applies it (which path each asset is on, and in what order to migrate) and a versioned, reproducible ruleset that resolves it the same way across every tier.
A verified ruleset
The ruleset is proven against an expected-verdict test harness across stratified cases and real hardware, Windows Server with AD CS and Linux hosts included, so every classification is reproducible and defensible. A public edge scan is the free first step; internal infrastructure, where a public scan cannot reach, gets the same validated engine run in your own boundary.
Mapped to your controls
Every finding lands on the control your assessment is measured against
The overlay carries each asset past the algorithm to the NIST 800-53 control behind it: the CBOM itself to CM-8, the cryptography to the SC family (SC-8, SC-12, SC-13, SC-17, SC-28), then re-labels it in your regime's dialect, federal RMF or a commercial framework like SOC 2 or PCI DSS. What lands on the assessor's desk is evidence they already know how to read.
Inventory to CM-8, cryptography to SC
The CBOM satisfies the component-inventory control directly, and each cryptographic finding maps to the System & Communications Protection family your authorization package is graded on.
Your regime's dialect
The same 800-53 mapping re-labels into the framework you answer to (NIST AI RMF, ISO 42001, SOC 2) so each finding speaks the language of your audit.
Assessment-ready evidence
Each row carries its control reference into the package your program already requires, an RMF authorization package or a PCI DSS 12.3.3 response plan: the mapping that turns a cryptographic inventory into assessment evidence.
Prove progress
Migration is multi-year. So is the evidence.
The first assessment sets a baseline. Re-run it against that baseline and it reports what moved: remediation closed, new exposures surfaced, any asset that slipped back to a vulnerable algorithm, and where the readiness score sits now. Each re-assessment is continuous-monitoring evidence your framework already asks for, RMF or PCI DSS 12.3.3's annual review.
Score movement over time
The readiness grade tracks across the phases your mandate sets, the 2030 and 2031 EO deadlines for federal systems, or PCI's annual 12.3.3 review for commercial ones, so leadership sees measurable progress against the mandate.
Remediation and regression
Every delta names what was closed, what appeared, and any asset that slipped from safe back to vulnerable, the churn a multi-year cryptographic migration accumulates.
Continuous-monitoring evidence
Each re-assessment maps to NIST 800-53 CA-7 and CM-8 for federal programs, or PCI DSS 12.3.3's annual review requirement for commercial ones: the ongoing evidence a program maintains between assessments.
Ongoing · PQC Program
Make FEDLIN the owner of your migration.
Someone has to own the migration and its annual re-review, on the federal timeline or PCI DSS 12.3.3. The Program makes FEDLIN that owner, in writing. We run the prioritized queue in reversible moves and keep the evidence current for as long as your mandate runs. From ~$2,000/month, scoped to the boundaries under management, a bounded subscription rather than open-ended hours.
Quarterly re-inventory
A delta re-assessment each quarter: what closed, what appeared, what regressed, and where the readiness score sits. The continuous-monitoring evidence your RMF (CA-7, CM-8) or PCI DSS 12.3.3 annual review already asks for.
Roadmap maintenance
The migration sequence updated as systems change and standards move, so the plan on file always reflects the estate you actually run.
Attestation refresh
A re-signed, tamper-evident deliverable each cycle, so the evidence you hand an assessor is always current.
A named migration owner
A capped monthly advisory allotment with a named PQC engineer, for the questions a mandate raises between assessments. Bounded, so it stays a subscription.
Priced as a subscription and scoped to your estate on the free scoping call. It packages the delta re-assessment and advisory into one bounded engagement.
Data custody
Four delivery postures: you pick where the data goes
A cryptographic map is itself a sensitive artifact. The discovery pipeline is identical across all modes; what differs is data egress and access posture, so a CUI-bearing system, a commercial one, and a provider-hosted one with no boundary of its own can use the same engine at different postures.
Export-then-overlay
The default for commercial, non-CUI work. Discovery output is analyzed with the CNSA 2.0 overlay and architect review. Fastest path to a delivered roadmap.
In-boundary, zero egress
A portable toolkit (one container image plus an offline air-gap bundle) runs entirely inside your environment on a local model. Nothing leaves the tenant. The delivery posture for federal and CUI-bearing systems.
Deterministic ruleset
No AI in the compliance path at all: a deterministic ruleset produces the mapping, for environments that require it. Available on request.
No-touch, declaration-sourced
Discovery is limited to a system declaration your team provides. Nothing is installed or executed in your environment, no endpoints are probed, and no access is granted. The inherited surface is documented by inquiry into your providers.
For federal subcontractor and CUI-bearing systems where FEDLIN is granted access, the assessment is delivered in-boundary (Mode B or C); Mode A (export) is not used for those systems. Where no access is granted, Mode D is the posture: declaration only, no scan. All modes read cryptographic metadata only (public certificates and algorithm identifiers), never private keys or secret values.
Is your TLS quantum-vulnerable?
Enter any public hostname to check its key exchange, certificate, and TLS configuration for post-quantum readiness and weak settings.
Unable to scan
Email these results to yourself
FEDLIN receives a copy and may follow up.
Check your inbox.
This scan covers your public TLS surface only. In-boundary endpoints, firmware, code dependencies, and your full cryptographic inventory require a dedicated assessment.
scan_post_quantumathttps://mcp.fedlin.com/mcpWhat you receive
A sample of the deliverable
Illustrative, sanitized output: cryptographic metadata only, no private keys or secret values. The measured table surfaces runtime assets a source-only scan can't see; the declared table shows the inherited surface and provider inquiry entries unique to the no-touch scope. Every finding is ranked, given a target, and mapped to the NIST 800-53 control your RMF already tracks.
Full-system assessment, synthetic example
| Cryptographic asset | Where it lives | Quantum status | CNSA 2.0 target | 800-53 | Priority |
|---|---|---|---|---|---|
| RSA-4096 sealing key over secrets in version control | Secrets-at-rest / GitOps | Broken: HNDL today | ML-KEM-1024 + key rotation | SC-12, SC-28 | Critical |
| RSA-2048 PKI leaf + intermediate certs (~175) | TLS termination, internal PKI | Broken by CRQC | ML-KEM-1024 / ML-DSA-87 | SC-13, SC-17, SC-12 | High |
| sha256WithRSAEncryption cert signatures | PKI cert chains | Broken by CRQC | ML-DSA-87 | SC-13, SC-17 | High |
| ECDH key exchange (P-256, x25519) | TLS 1.2/1.3 + SSH | Broken: HNDL on captured sessions | ML-KEM-1024 (hybrid KEX) | SC-8, SC-12 | High |
| ECDSA P-256 host/auth keys | SSH host keys, service auth | Broken by CRQC | ML-DSA-87 / LMS/XMSS | SC-12, SC-17 | Medium |
| AES-256-GCM at rest + in transit | Datastore, TLS records | Quantum-resistant | No change | SC-28 | None |
Boundary assessment, provider-hosted scenario
| Cryptographic asset | Where it lives | Status | Target | 800-53 | Priority |
|---|---|---|---|---|---|
| RSA-2048 root CA, 10-yr validity | Internal AD CS (declared) | Forgeable once broken | ML-DSA-87 | SC-12, SC-17 | Critical |
| M365 / GCC tenant cryptography | Provider-managed | Not externally observable | Provider inquiry | SA-9, CA-3 | Inquiry issued |
Declared-scope findings are built from assets your team declares and provider inquiry responses, with nothing run inside your environment. See the measured posture for runtime discovery.
Read-out for a security officer: the RSA and ECC rows are quantum-vulnerable; the sealing key and ECDH carry harvest-now-decrypt-later exposure today. AES-256 is already quantum-resistant: Grover's algorithm only halves its effective strength, and no action is needed. Every row maps to an 800-53 control (CM-8, SC-8, SC-12, SC-13, SC-17, SC-28); the inventory itself satisfies CM-8 and serves as the cryptographic-inventory record for your M-26-15 Phase 1 submission.
CycloneDX 1.6 CBOM excerpt (Full-System deliverable, machine-readable)
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"metadata": {
"component": { "type": "application", "name": "example-agency-system" },
"properties": [
{ "name": "fedlin:overlay-mode", "value": "C (deterministic, in-boundary)" },
{ "name": "fedlin:coverage", "value": "static + runtime detectable; edge/CDN and dynamically-loaded crypto out of scope" }
]
},
"components": [
{
"type": "cryptographic-asset",
"name": "RSA-2048 (PKI signing)",
"cryptoProperties": {
"assetType": "algorithm",
"algorithmProperties": {
"primitive": "signature",
"parameterSetIdentifier": "2048",
"classicalSecurityLevel": 112,
"nistQuantumSecurityLevel": 0
},
"oid": "1.2.840.113549.1.1.11"
}
},
{
"type": "cryptographic-asset",
"name": "RSA-2048 (key transport)",
"cryptoProperties": {
"assetType": "algorithm",
"algorithmProperties": {
"primitive": "pke",
"parameterSetIdentifier": "2048",
"classicalSecurityLevel": 112,
"nistQuantumSecurityLevel": 0
},
"oid": "1.2.840.113549.1.1.1"
}
}
]
}Standards & Framework Coverage
FAQ
Common Questions
Is there a deadline for private companies, or is this only a federal requirement?
The hard, dated deadlines are federal. Executive Order 14412 sets 2030 for key establishment and 2031 for digital signatures on federal systems, with a proposed FAR rule that would extend that to covered contractors. For private companies there is no post-quantum mandate today. What sets the timeline instead is your own environment: customer security reviews, cyber-insurance questions, TLS certificates that now expire far faster, new federal and FIPS-keyed procurements that now expect FIPS 140-3 (FIPS 140-2 validations moved to NIST's Historical list on September 21, 2026), and data that must stay confidential for years, since encrypted data captured today can be decrypted later. The practical step is to inventory your cryptography and have a plan ready before a customer or auditor asks for one.
We don’t have a security team or a cryptographer. Can you just do this for us?
Yes, and that is who this is built for. You do not need in-house cryptography expertise. You own the requirement; FEDLIN does the work: inventorying the cryptography you run, mapping it to the standards your program is measured against, and returning a prioritized migration plan. For a smaller footprint the entry assessment is declaration-based, so you describe your systems in one intake session and FEDLIN produces the inventory and the plan from there.
What does a post-quantum readiness assessment cost?
PQC Readiness is the cryptographic inventory, priced per production environment: $5,000 the first year, then $2,000 for the annual re-review (one environment can be a PCI DSS 12.3.3 cardholder data environment). Federal work is delivered through your prime or integrator under a scoped, fixed-price subcontract. Most engagements are a single boundary, assessed declared (no-touch) or measured (in-boundary) and sized from the free scan. Implementing the migration is quoted separately under crypto-agility engineering.
Do we have to migrate now, or just have a plan?
For almost everyone the near-term expectation is a plan, with the migration itself following from it. Every roadmap starts the same way: an inventory of the cryptography you run, then a prioritized, sequenced migration plan. You migrate the highest-risk, longest-lived cryptography first, on a timeline you can defend. FEDLIN produces the inventory and that sequenced plan; the migration follows at a pace that fits your systems and budget.
What exactly do we get at the end?
A plain-language readiness report you can hand to a customer, an auditor, or leadership, backed by a machine-readable cryptographic inventory (a CBOM), a prioritized migration roadmap, and a crosswalk to the security controls your program is assessed against. For production systems you also get a readiness score you can track over time as you migrate.
What is a CBOM, and why does the federal guidance start with one?
A Cryptographic Bill of Materials is a machine-readable inventory of the cryptography a system uses (algorithms, key lengths, certificates, and where each lives), delivered in the ECMA-424 (CycloneDX) format standard. Every federal PQC mandate begins with an inventory: OMB M-26-15 makes it the Phase 1 deliverable (agency plans due October 2026). The CBOM is the inventory core of that filing. The inventory is the gating first step; the CNSA 2.0 judgment on top is the part a team cannot self-serve.
Is this an audit or a certification?
No. It is a readiness assessment and an engineering roadmap, separate from an audit, certification, or attestation; the assessor or authorizing official renders that opinion. The CBOM covers cryptography detectable by static and container analysis across the defined scope; runtime-negotiated and dynamically loaded cryptography is noted as out of static reach, and heuristic findings carry a confidence level.
Does my cryptographic map leave my environment?
Only if you choose that mode. The assessment runs in one of four modes by data egress: (A) export-then-overlay, the commercial default; (B) an in-boundary portable toolkit that runs entirely inside your environment with zero egress; (C) a deterministic ruleset with no AI in the compliance path; and (D) no-touch, declaration-sourced discovery from a system declaration you provide, with nothing installed, executed, or probed in your environment. For federal or CUI-bearing systems, the in-boundary form is the delivery posture.
What is the CNSA 2.0 decision layer, and why does it matter?
Open-source tooling produces the raw inventory. The defensible work is mapping each asset to the correct target: the National Security System path (ML-KEM-1024, ML-DSA-87, LMS/XMSS for firmware signing) held distinct from the commercial path (SLH-DSA / FIPS 205), sequenced by break-priority and data longevity. That NSS-vs-commercial judgment, and the migration sequence, are what a scan alone does not give you.
Is FEDLIN FedRAMP authorized?
The assessment is delivered data-custody-free (in-boundary for CUI-bearing systems) and is not a FedRAMP system of record. Because the toolkit runs inside your boundary and nothing egresses, there is no cloud service to authorize: FedRAMP governs cloud offerings that hold agency data, and this deliverable holds none.
How do federal agencies and contractors buy this?
Through your prime or integrator. FEDLIN works as the engineering subcontractor behind the firm that holds the contract, delivering the assessment as scoped work at a fixed price the prime can mark up. The Capability Statement carries our identifiers, NAICS codes, and key personnel for a proposal. Nothing leaves your boundary, so there is no system to authorize. A short scoping call and a Statement of Work confirm exact scope before work begins.
What did the June 2026 executive order change?
Executive Order 14412 (June 22, 2026) sets federal deadlines (key establishment on sensitive systems by December 31, 2030, digital signatures by December 31, 2031), with a proposed FAR rule that would pull covered contractors in by the end of 2030. OMB M-26-15 (June 24, 2026) gave agencies 120 days to submit a migration plan to OMB and the National Cyber Director, aligned to the draft NIST IR 8547. PQC moved from recommendation to a dated requirement.
Do you fix what the assessment finds, or only report it?
We fix it. That means putting the replacements in place: hybrid post-quantum key exchange at your edge, validated cryptographic modules underneath the systems that need them, and long-lived signatures where a record has to stay verifiable for years. Federal systems also get the migration to the higher national-security suite, sequenced and scoped per engagement. Each change is reversible and lands in your Risk Register with the evidence that it’s done.
Does this apply to on-chain or blockchain systems?
Cryptographic longevity is particularly acute for on-chain records, public and permanent by design. A signature anchored today has to remain trustworthy for the life of the record. FEDLIN implements SLH-DSA (FIPS 205) for exactly this, the same stateless hash-based scheme the assessment maps quantum-vulnerable signatures toward. The assessment scopes to the off-chain system that issues, manages, and anchors signatures, the boundary where the migration work lives.
From the Blog
The field guide, in depth
Post-Quantum Roadmap by October: Where to Start, and the Questions to Ask First
The roadmap is due in October. If you haven't started yet, here are actions you can take today to get a jump-start: where to begin, the questions that decide your first moves, and a free scan that puts a data point on the board.
Before the Algorithm: Where a Post-Quantum Plan Really Starts
The deadline lands and the instinct is to pick an algorithm. The plan actually starts a few phases earlier, and the hard part is the calls you make in the middle.
Taking Inventory: You Can't Migrate the Cryptography You Can't See
A federal mandate now requires agencies to inventory the cryptography they're running, with acquisition rules written to reach the contractors who serve them — and mandate or not, you can't migrate what you can't see. My FIPS 140-3 rebuild gave me a validated floor but didn't tell me what was standing on it, so I built the tool that takes the inventory — a secret-safe capture of a live system's cryptography with the CNSA 2.0 judgment on top — against my own cluster first, then for the estates that look nothing like it. It's the first deliverable of FEDLIN's Post-Quantum Readiness service.
Often scoped together
Related engineering, delivered on its own or folded in
GRC Engineering
Full compliance program implementation: SSP, evidence pipeline, and framework attestation.
Data Sovereignty Engineering
Security architecture for agentic systems handling sensitive cryptographic operations.
Penetration Testing
Adversarial testing that validates cryptographic controls and key management boundaries.
Start with the inventory you already owe.
See if your encryption is quantum-vulnerable in seconds, free and no signup. When you're ready, a scoping call sizes the assessment: a Cryptographic Bill of Materials, a CNSA 2.0 mapping with the NSS-vs-commercial path called out, and a sequenced migration roadmap, delivered in-boundary where the data can't leave.
Ready to start your cryptographic inventory?
Pick the scope that matches what you run. We'll confirm on the call.