The cryptographic engineering running through all of it. Crypto-Agility Engineering
Cryptography shows up everywhere: the signature behind your email, the cipher suite your edge negotiates, the algorithm that signed a document ten years ago and has to prove it today. FEDLIN engineers the cryptography across all of it as one practice.
The foundation beneath the AI you self-host and the engineering that follows a Post-Quantum Readiness Assessment.
Engineered by Jeremiah Coakley, Principal Security Architect
Where it shows up
Cryptographic engineering across the stack.
Every context below involves cryptography that can age out, deprecate, or fail under a deadline. FEDLIN engineers it as one practice across all of them.
Email authentication
DKIM is a digital signature. The key behind it has an algorithm, a length, and a rotation cadence. When any of those age out, email deliverability and spoofing protection degrade together. Getting DKIM right is a cryptographic operation, not just a DNS record.
Why p=none is not email protection →Edge TLS and cipher suites
Every connection your edge terminates negotiates a TLS version and a cipher suite. Whether those suites provide forward secrecy, whether they are still considered strong, and whether your certificates expire before you can reissue them are all crypto-agility questions, answered at the edge, not the application.
Edge Security →Workload identity
SPIFFE/SPIRE gives every workload a cryptographic identity: a short-lived X.509 certificate issued and rotated automatically. The algorithm behind those certificates, the CA that issues them, and the rotation schedule all require the same discipline as any other cryptographic infrastructure.
Workload identity on OpenShift →Long-lived record signing
A document, ledger entry, or audit trail signed today and kept for decades needs a signing algorithm that outlasts its retention period. RSA and ECDSA may not. FEDLIN has engineered SLH-DSA (FIPS 205) signatures into a production platform built for this problem: records anchored in a way that remains verifiable long after today's algorithms are deprecated.
Post-quantum signing for permanent records →Self-hosted AI workloads
Every self-hosted AI workload FEDLIN builds ships on a FIPS 140-3 cryptographic foundation with PQ-ready signing and automated certificate management built in. The cryptographic posture is a default of the build, not a configuration option.
Self-Hosted AI Security →Post-quantum migration
CNSA 2.0 and OMB M-26-15 set deadlines for migrating to NIST-standardized post-quantum algorithms. The first step is a cryptographic inventory: a CBOM of everything you run, scored against the PQC Maturity Model. The engineering follows from it.
Post-Quantum Readiness Assessment →Delivered work
Crypto-agility, at every layer it lives.
Deprecated cryptography has nowhere to hide. FEDLIN keeps the stack current from the application layer all the way down.
Is this only about post-quantum?Records / application
In production
Long-lived post-quantum signatures on the NIST hash-based standard (SLH-DSA), built to stay verifiable for decades.
Transport
Deployed and verified
Modern TLS floors, HSTS, CAA, and DNSSEC deployed across live domains, then verified with an independent check you can re-run.
Firmware
Delivered, regulated environment
Deprecated firmware cryptography brought to a current, supported floor, below the reach of the application layer.
Cryptographic module
FEDLIN's own cluster
A FIPS 140-3 validated foundation, kept crypto-current as the standards move.
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 Common questions
What is crypto-agility?
Crypto-agility is the ability to change the cryptography your systems use (the algorithms, keys, and certificates) without re-engineering the systems around them. It matters because cryptography keeps changing: certificates expire faster, post-quantum standards are replacing today's algorithms, and older schemes get deprecated. An agile setup lets you swap what is underneath on demand instead of rebuilding under deadline.
Is crypto-agility only about post-quantum?
No. Post-quantum migration is the largest current driver, but crypto-agility also covers the shrinking lifetimes of TLS certificates, long-lived signatures that must outlast today's algorithms, FIPS-validated cryptography for regulated data, and the cryptographic identity your workloads use. FEDLIN engineers all of these as one practice.
Have you actually built this, or do you just advise on it?
Built it. FEDLIN has engineered post-quantum signatures into a production platform made to keep signatures valid for decades, deployed TLS and certificate hardening across live production domains, and keeps the cryptographic module on its own infrastructure current and FIPS 140-3 validated. The work is delivered and running.
Which post-quantum algorithms do you implement?
FEDLIN implements SLH-DSA (FIPS 205, formerly SPHINCS+) for long-lived digital signatures, ML-KEM (FIPS 203) for key establishment, and ML-DSA (FIPS 204) for general digital signatures. These are the three NIST-standardized post-quantum algorithms required under CNSA 2.0 and OMB M-26-15. Algorithm selection is driven by your use case.
From the Blog
From the field notes
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.
Not sure where to start? Tell us where you are.
Evaluating your security posture before a funding round, compliance deadline, or enterprise deal?