Prove your post-quantum readiness on the scale your customers will use. Post-Quantum Readiness
The threat is already active: adversaries capture encrypted traffic today and hold it until the capability to decrypt it arrives. Post-quantum readiness has also become a supply-chain question: your customers ask where you stand on a shared scale, the PKI Consortium's PQC Maturity Model. Answering both requires a scored inventory, a migration sequenced by risk, and an evidence package that maps to the level they require. FEDLIN delivers all three.
Post-quantum readiness is one part of FEDLIN's crypto-agility engineering →
Free scan. No signup.
Engineered by Jeremiah Coakley, Principal Security Architect
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.
Rung 1 · Readiness report
Where you stand today
A CycloneDX CBOM of the cryptography you run, scored as your current PQCMM level, with the gaps that hold it there.
Rung 2 · Remediation
The level your customers require
We engineer the migration to your target level and produce the evidence package that proves it, on the deadline you're held to.
Architecture and engineering
Two deliverables. Sold together or on their own.
Every FEDLIN engagement separates the architecture decision (which controls, where, and why) from the engineering that builds and runs them in your environment. Each stands on its own, and together they carry a requirement from design through proof.
Design authority
The architecture decision
What cryptography is actually running, judged against the CNSA 2.0 target, and sequenced by what breaks first if you wait. That judgment (which asset moves, in what order, to which target) is the part a scan alone does not give you.
Engineering proof
What gets built
A CycloneDX CBOM built from a live system, every finding judged rather than just captured, delivered as a container that runs inside your own boundary.
Where this fits
The assessment opens the migration. The engineering implements it.
The CBOM and roadmap are the first deliverable — the inventory and sequencing your mandate requires. Implementing the migration (post-quantum signing, key establishment, cipher-suite transitions) is the next step, handled under Crypto-Agility Engineering. The two engagements connect: the assessment scopes the work, the engineering delivers it.
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 and superseded the 2022 M-23-02 inventory memo. 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 move 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
The mandated inventory, without the headcount
Resource-constrained agencies where one person may be the security officer, the IT lead, and the privacy officer at once - carrying the same M-26-15 Phase 1 inventory obligation and PQC timeline as an agency with a cryptography team. The cryptographic inventory is the core of the filing they owe; the declaration-only mode keeps the data where it has to stay.
Contractors, primes & the CUI supply chain
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.
FinTech, HealthTech & signed records
Platforms handling payments, PHI, 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.
Engagements
Two assessments and an engineering path.
The right entry depends on whether you need to know what's there or build what's needed. Assessments produce a CBOM and roadmap. Engineering implements the migration.
Boundary Assessment
$5,000 flat
Card-buyable under the $15K federal micro-purchase threshold
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 agencies without an on-prem footprint, it produces the inherited-control register and the inventory-methodology inputs your OMB M-26-15 Phase 1 submission draws on.
Fixed scope: one declared authorization boundary, captured from a declaration template your team completes, in a single intake session. Larger estates are sized on the free scoping call and route to the Full-System Assessment, so the fixed price stays fixed.
Best for
- → Federal agencies using managed services and cloud platforms
- → Organizations meeting OMB M-26-15 Phase 1 without on-prem infrastructure
- → Organizations that inherit most of their cryptography from providers
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
Full-System / Estate Assessment
Quoted per engagement
Scope driven by number of systems, boundary size, and data-custody posture. Free scoping call to size it.
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.
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 alongside the CBOM for authorization support
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: validated CycloneDX 1.6 CBOM, executive scorecard (readiness score, letter grade, exposure counts, harvest-now-decrypt-later callouts), sequenced owner-assigned migration roadmap, and detached SLH-DSA (FIPS 205) attestation the recipient can verify against the delivered artifacts
The register is your Phase 1 inventory input.
The inherited-control register and provider inquiry set are the inventory inputs your OMB M-26-15 Phase 1 submission draws on, produced inside your boundary, with no FedRAMP authorization, ATO, or contract vehicle required, because nothing leaves the boundary to authorize. Card-buyable at the entry tier under the micro-purchase threshold.
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 47-day TLS-certificate cliff. From there it routes into the Security Program that implements the roadmap and owns crypto-agility as the standards move.
Both assessments deliver
Full-System also delivers
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 a Cryptographic Bill of Materials
Every migration begins with knowing what you have. Where FEDLIN measures your systems, that inventory is delivered as a machine-readable CBOM — where RSA, ECDSA, and other quantum-vulnerable algorithms live, at which layer, protecting what. The declaration-based Boundary tier delivers the same picture as the inherited-control register. What a CBOM contains and how it's used →
A CycloneDX CBOM
The inventory is delivered as a Cryptographic Bill of Materials in the ECMA-424 (CycloneDX) format standard - machine-readable, diffable, 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 - 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 crypto 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 crypto. 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 - 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.
Mapped to your controls
Every finding lands on the 800-53 control your RMF is assessed against
The overlay carries each asset past the algorithm to the NIST 800-53 control behind it - the CBOM itself to CM-8, the crypto to the SC family (SC-8, SC-12, SC-13, SC-17, SC-28) - then re-labels it in your regime's dialect. What lands on the assessor's desk is evidence they already know how to read.
Inventory to CM-8, crypto to SC
The CBOM satisfies the component-inventory control directly, and each crypto 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 (SOC 2, NIST AI RMF, ISO 42001) so each finding speaks the language of your audit.
RMF-ready evidence
Each row carries its control reference into the package your RMF already requires - the mapping that turns a cryptographic inventory into assessment evidence.
Prove progress
Migration runs to 2035. So does 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 the RMF already asks for.
Score movement over time
The readiness grade tracks across the phases the federal timeline sets - from the 2030 and 2031 EO deadlines to the 2035 endpoint - 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 crypto migration accumulates.
Continuous-monitoring evidence
Each re-assessment maps to NIST 800-53 CA-7 and CM-8 - the ongoing-authorization evidence a program maintains between the mandate's phases.
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 an agency 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 rather than by scan.
For federal and defense CUI where FEDLIN is granted access to the systems, the assessment is delivered in-boundary (Mode B or C) - Mode A (export) is not used for those systems. Where no access is granted - the Boundary tier for provider-hosted federal micro-agencies - 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.
How you run it
Run it by hand, or drive it with AI you already have
The container is the same either way - what changes is how your team operates it. The inventory never depends on a model: the discovery pipeline is deterministic. AI is confined to one optional step - drafting the migration roadmap on top of findings that are already resolved - and where that runs is entirely your call.
A deterministic tool, no AI required
Your engineer runs the image by hand or in CI. Discovery captures the live crypto surface, the versioned CNSA 2.0 ruleset resolves each asset to its target, and the CBOM validates against the CycloneDX schema - every step reproducible, with a hashed artifact. This is the default when "AI in the compliance path" is off the table: fully deterministic, fully defensible.
Driven by a model that never leaves your boundary
Point an AI agent at the optional roadmap step and run it inside your own environment - on a self-hosted model such as Ollama, so the cryptographic map and the analysis around it stay in your tenant. No new AI vendor to procure, no new data-sharing agreement: the assessment meets the AI you already run.
You don't need a frontier AI contract to run it
The assessment is built to meet the tools an agency already has. Where your data-custody posture permits egress, the roadmap step can be driven by a hosted assistant your team is likely already licensed for - Microsoft Copilot in a Microsoft 365 tenant, or ChatGPT. Where the data can't leave - CUI, or anything under a no-egress mandate - the same step runs on a self-hosted model such as Ollama, entirely inside your boundary. Either way, what leaves your environment is nothing: the inventory, the analysis, and the roadmap stay where you run them.
Pointing any AI at a cryptographic inventory is precisely where a stray prompt or an over-scoped agent becomes a risk - so the governance around that model matters as much as the model. Standing up that guardrail layer around your own AI, so you can run assessments like this one and the agents you already operate safely, is a service in itself: governance for the AI you run yourself.
Is your TLS quantum-vulnerable?
Enter any public hostname to check its key exchange algorithm and certificate for post-quantum readiness.
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_quantum at https://mcp.fedlin.com/mcp What you receive
A sample of the deliverable
Illustrative, sanitized output - cryptographic metadata only, no private keys or secret values. The full-system table surfaces runtime assets a source-only scan can't see; the Boundary Assessment 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-agency
| 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, ICP 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 crypto | Provider-managed | Not externally observable | Provider inquiry | SA-9, CA-3 | Inquiry issued |
Boundary-scope findings are built from assets your team declares and provider inquiry responses, with nothing run inside your environment. See the Full-System Assessment for measured 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, 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?
The entry Boundary Assessment is $5,000 flat, buyable on a purchase card under the $15,000 federal micro-purchase threshold, with no contract vehicle required. A full-system or estate assessment, which measures live cryptography across production systems, is quoted per engagement after a free scoping call. Implementing the migration is also quoted per engagement.
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), carrying forward the 2022 M-23-02 memo it supersedes. 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 crypto 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. FEDLIN builds to the FIPS 203/205 algorithm standards and the NIST 800-53 control families a program is assessed against; a formal authorization path is scoped per engagement and to the client’s boundary, not claimed here.
Do we need a contract vehicle - or FEDLIN in SAM - to buy the entry assessment?
Generally, no. The entry assessment is priced under the $15,000 federal micro-purchase threshold, which a cardholder can buy on a government purchase card without a contract vehicle. FAR 4.1102(a)(1) exempts purchases under that threshold from SAM registration when the purchase card is used as both the purchasing and payment mechanism, not when the card settles payment against a separate contract action. Your agency’s purchase-card policy governs, and cardholder single-purchase limits are often set below the FAR maximum. Nothing leaves your boundary, so there is no system to authorize.
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.
What has FEDLIN actually built?
FEDLIN has implemented hybrid ML-KEM-768 (FIPS 203) key establishment on a FIPS 140-3 foundation, and SLH-DSA (FIPS 205) as the signing layer for a document-integrity platform with blockchain hash anchoring - hands-on with the same migration the assessment sequences. That hands-on deployment used the commercial parameter set (ML-KEM-768). For national security systems, FEDLIN maps and sequences the migration to the higher CNSA 2.0 suite (ML-KEM-1024, ML-DSA-87); that deployment is scoped per engagement. The assessment engine builds on open-source discovery (CBOMkit, CycloneDX) with FEDLIN’s CNSA 2.0 overlay as the decision layer on top.
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 has implemented SLH-DSA (FIPS 205) long-lived signatures with blockchain hash anchoring on a deployed document-integrity platform, which is 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
Related reading
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.
What the 2030 Federal Encryption Deadline Means for Your Contracts
A June 2026 executive order set hard 2030 and 2031 deadlines for moving federal systems to quantum-resistant cryptography — with acquisition rules written to pull in the contractors who serve them. In plain terms: what it means, the move to make now, and the first steps to get ahead.
Often scoped together
Related engineering, delivered on its own or folded in
GRC Engineering
Full compliance program implementation - SSP, evidence pipeline, and framework attestation.
Self-Hosted AI Security
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.