AffixIO and NIST: where the implementation aligns and where it does not

AffixIO

NIST alignment

Which NIST standards AffixIO implements, and which it does not.

Every verification outcome is signed with ML-DSA-65, the post-quantum algorithm NIST standardised in FIPS 204. That is a statement about an algorithm, not a certificate, and the two get blurred constantly. This page separates them across twenty publications, marks each one honestly, and gives you the commands to check the important claims without trusting the page.

Read the alignment table Verify it yourself

Last reviewed 14 August 2026 against the running implementation. Written for security reviewers and cryptography engineers.

Engineering drawing of a klystron K-band amplifier and a klystron S-K multiplier, annotated with waveguide, cavity and tuning components — A standard is only useful when someone writes down the dimensions. Klystron schematic from an early NIST atomic clock, National Institute of Standards and Technology, public domain.

Position

The short version, in one paragraph

AffixIO signs with ML-DSA-65 under FIPS 204 and hashes with SHA-256 under FIPS 180-4, and it holds no cryptographic module validation of any kind. The post-quantum signature is real, in the request path, and verifiable offline against a public key we publish. The validation is absent, and nothing on this site is worded to suggest otherwise. Where a NIST publication describes something we have only partly done, such as key custody or secure development practice, the gap is named in the table rather than rounded up to a tick.

Signature scheme: ML-DSA-65, FIPS 204
Hash and audit: SHA-256, FIPS 180-4
Module validation: None. No CMVP certificate.
Control assessment: None. SP 800-53 and CSF 2.0 not assessed.

This page describes an implementation, not a legal position, and it is not advice on your own obligations. If you need the same detail inside a vendor questionnaire or a supplier assurance pack, ask and we will complete yours directly. For UK NCSC timelines see the NCSC alignment page. For US CISA guidance see the CISA alignment page.

Standard or certificate

The distinction most post-quantum marketing skips

Nearly every question we get about NIST is really this question, so it is worth answering before the table.

An algorithm standard says what to compute

FIPS 204 specifies ML-DSA: the key sizes, the signing procedure, the verification procedure. It is a public document and anyone may implement it. Saying that a product uses ML-DSA-65 is a claim about which mathematics runs, and it can be checked by looking at the output.

AffixIO makes this claim, and the checks in the section below let you confirm it in about ten seconds.

A validation says who tested the build

FIPS 140-3 is not an algorithm. It is a validation programme in which an accredited laboratory tests one specific cryptographic module, at a specific version, running in a specific configuration, and NIST issues a numbered certificate through the Cryptographic Module Validation Program.

AffixIO does not make this claim. There is no certificate, the signing code is a pure software implementation, and the runtime is not configured in a FIPS mode.

The practical consequence is narrow but real. If your procurement rule requires a validated module, correct post-quantum mathematics does not satisfy it, and no amount of standards language on a vendor page changes that. Tell us early if that is your constraint, because the honest answer today is that we do not meet it.

Alignment

Twenty publications, each with a status

Filter by status. Every entry in the detail column describes the running implementation rather than a roadmap.

AffixIO alignment with NIST publications, reviewed 14 August 2026 against the running implementation.
Publication	Status	What the implementation actually does
FIPS 204Module-lattice digital signatures	Implemented	Every verification outcome is signed with ML-DSA-65, the parameter set targeting security category 3. The public key is published at `/.well-known/affix-mldsa65.json` and measures 1952 bytes, which is the length FIPS 204 fixes for this parameter set. Signing runs in software through the noble post-quantum library.
FIPS 180-4Secure hash standard, SHA-2	Implemented	SHA-256 produces the payload digest that gets signed, both the leaf and node hashes in the Merkle audit tree, the signing key identifier, and the PKCE challenge on the OAuth path. Leaf and node hashing use separate domain-separation prefixes so a leaf can never be reinterpreted as an internal node.
FIPS 198-1Keyed-hash message authentication	Implemented	HMAC-SHA256 authenticates webhook deliveries and signed tickets, and it backs the Affix Light proof scheme in the lightweight SDK. Light proofs are a keyed message authentication code and are not zero-knowledge proofs; the SDK says so in the source and so do we.
SP 800-131A Rev 2Algorithm and key-length transitions	Aligned	There is no RSA and no elliptic curve signature anywhere in the attestation path, so there is nothing in it to transition away from. This is satisfied by construction rather than by a migration project, which is the cheapest way to satisfy it.
NIST IR 8547Post-quantum transition, initial draft	Aligned	The draft describes an expected approach in which 112-bit classical algorithms are deprecated after 2030 and disallowed after 2035. Those dates are not final. AffixIO already signs with a standardised post-quantum scheme, so the signature path carries no migration debt against either date.
NIST Privacy FrameworkPrivacy risk management	Aligned	Data minimisation is architectural here rather than procedural. On the standard path the proof is generated on your host, and what reaches AffixIO is a proof, its public inputs and a set of digests, not names or document numbers. See the compliance page for the record-by-record retention ledger.
NIST AI RMFAI risk management framework	Aligned	Applied directly in the AI model usage policy gate, which evaluates registry, entitlement, residency, safety and scope rules and returns allow or deny before a prompt reaches a model. The framework is cited on that page alongside the OWASP list for model-backed applications.
SP 800-57 Part 1 Rev 5Key management recommendations	Partial	There is one active signing key. It carries an identifier derived from the SHA-256 digest of its public half, that identifier appears on every attestation, and the public key is published so verification never needs to contact us. What is missing is custody: the private key is a file on the host, not an HSM or a managed key service, and rotation happens on request rather than on a fixed cryptoperiod.
SP 800-90A Rev 1Random bit generation	Partial	Key material, nonces and tokens all come from the platform generator seeded by the operating system entropy source. There is no home-made randomness anywhere in the codebase, which is the failure mode this publication exists to prevent. It is not a validated DRBG, because validation belongs to FIPS 140-3 and we hold none.
SP 800-63BDigital identity, authenticators	Partial	Hub passwords are stored as scrypt derivations with a per-user random salt and compared in constant time. API keys are long random bearer tokens. The gap worth stating plainly: those keys are stored on disk in readable form rather than as verifier-side hashes, so host access means key access. Rotate through Hub if that matters to your threat model.
SP 800-207Zero trust architecture	Partial	Every request authenticates on its own merits and is rate limited per key, with no trust granted by network position, and the verification path holds no identity records that a lateral move could harvest. Continuous device posture assessment and per-session policy evaluation are not implemented, so this is a partial alignment rather than an architecture claim.
SP 800-218Secure software development framework	Partial	Dependencies are pinned in a lockfile and the proving path has an integration test for each circuit template. Against that: there is no software bill of materials, no automated dependency scanning in continuous integration and no signed release artefact. Those are gaps in our practice, and listing them here is more useful to you than omitting the row.
FIPS 202SHA-3 and the SHAKE functions	Not used	No AffixIO code calls SHA-3 or SHAKE directly. They are still present in the system, because ML-DSA-65 uses SHAKE128 and SHAKE256 internally exactly as FIPS 204 specifies. The function arrives through the signature scheme rather than through our own hashing.
FIPS 186-5Digital signature standard	Not used	No ECDSA, Ed25519 or RSA signature appears in the attestation path. The public browser tools on this site do sign a local record with ECDSA P-256 through the Web Crypto API, but that is a self-verifiable artefact produced in your own browser and it is never an AffixIO attestation. The two are labelled differently on purpose.
FIPS 203Module-lattice key encapsulation	Not used	The application performs no key establishment of its own, so there is nowhere for ML-KEM to sit. Transport encryption terminates ahead of the application, which means any hybrid or post-quantum key exchange is a property of that layer and not something this codebase can claim.
FIPS 205Stateless hash-based signatures	Not used	One signature scheme, by choice. SLH-DSA rests on different assumptions to ML-DSA and is a reasonable hedge, but a second scheme means every verifier has to implement both, and that cost buys nothing against the threats this service actually faces.
SP 800-208Stateful hash-based signatures	Not used	LMS and XMSS require signing state to survive every single operation, and reusing a one-time key destroys the security of the scheme. That constraint suits firmware and boot signing. It is a poor fit for a service that signs continuously.
FIPS 140-3Cryptographic module validation	Not claimed	No CMVP certificate and no validated module. Signing uses a software implementation with the runtime's default cryptographic provider and no FIPS mode configured. This is the single claim most often blurred by post-quantum vendors, which is why it has its own section above rather than a footnote.
SP 800-53 Rev 5Security and privacy controls	Not claimed	No control baseline has been assessed or attested, by us or by a third party, and no FedRAMP process has been entered. If your programme needs a control mapping, we will work through your catalogue with you, but we will not publish one that nobody has tested.
NIST CSF 2.0Cybersecurity framework	Not claimed	No current or target profile has been produced and no assessment has been carried out. The framework is a programme-level instrument, and publishing a self-scored profile would tell you about our marketing rather than about our security.

ImplementedThe algorithm or practice runs in the request path today and can usually be observed from outside.
AlignedGuidance the design already satisfies. There is nothing to install and nothing to certify.
PartialPart of it is done. The missing part is named in the same row rather than left out.
Not usedA standard that exists and that AffixIO deliberately does not need. The reason is given.
Not claimedSomething a reader might assume we hold. We do not hold it.

Evidence

Check the important claims yourself

The two claims that matter on this page are the signature scheme and the audit trail. Both are readable from public endpoints, so neither needs your trust.

Read the published signing key

No credential is needed. The response gives the algorithm, the public key as hex, and the time it was published.
```
curl -s https://api.affix-io.com/.well-known/affix-mldsa65.json
```
Returns "algorithm": "ML-DSA-65" with the public key and a publication timestamp.
Confirm the parameter set from the key length

This is the useful one. FIPS 204 fixes the ML-DSA-65 public key at 1952 bytes, so measuring the key proves the parameter set rather than accepting a label. A result of 1312 would mean ML-DSA-44 and 2592 would mean ML-DSA-87.
```
curl -s https://api.affix-io.com/.well-known/affix-mldsa65.json \
  | python3 -c "import json,sys; print(len(json.load(sys.stdin)['publicKey'])//2, 'bytes')"
```
Returns 1952 bytes.
Derive the key identifier that appears on attestations

The identifier is the first 16 hex characters of the SHA-256 digest of the published public key, prefixed with the scheme name. Deriving it locally lets you tie any attestation you hold to the key on this page.
```
curl -s https://api.affix-io.com/.well-known/affix-mldsa65.json \
  | python3 -c "import json,sys,hashlib; k=json.load(sys.stdin)['publicKey']; \
print('mldsa65-' + hashlib.sha256(k.encode()).hexdigest()[:16])"
```
Returned mldsa65-1bf342d458b982b2 at the time of review. It changes when the key is rotated.
Read the current audit root

The Merkle root covers every anchored decision digest. An inclusion proof for any single digest can be checked against this value without disclosing what the decision was about.
```
curl -s https://api.affix-io.com/v1/merkle/root
```
Returns root, leaf_count and updated_at.

If any of these return something other than what is described, the page is wrong and we want to know. Send the output to hello@affix-io.com and we will correct it or explain it.

Transition

Why the signature is already post-quantum

The reason to move a signature scheme early is not that a cryptographically relevant quantum computer exists. It is that migration is slow, and signatures made today are often still being relied on in ten years. Long-lived attestations inherit whatever assumptions were current when they were issued.

The related risk usually described as harvest now, decrypt later applies mainly to encrypted traffic that an adversary can store until decryption becomes feasible. It is a weaker argument for signatures, which fail differently: the danger there is that an attacker who can eventually forge a signature can forge one against records you issued years earlier and still depend on.

Both point the same way for an attestation service. Choosing a standardised post-quantum scheme at the start avoids a re-signing exercise across historical records later, and it means the FIPS 204 line in a procurement questionnaire is already answered. That was the reasoning, and it is worth being clear that it is an engineering trade rather than a claim about imminent quantum attack.

Crypto agility is the part still worth improving. Every attestation carries a key identifier and an algorithm name, so a verifier can tell which key and scheme produced it, and a second scheme could be introduced without breaking existing records. Automating rotation and moving the private key into hardware custody are the next steps, and neither is done yet.

Proof systems

Zero-knowledge and HMAC are not the same claim

AffixIO ships two proving paths. One is a zero-knowledge proof and one is a keyed integrity check. The terms are not interchangeable, and the difference is worth stating plainly for anyone auditing the cryptography.

@affix-io/sdk with UltraHonk: zero-knowledge

UltraHonk is a succinct proof system in the PLONK family, the Honk-based successor to UltraPlonk, implemented in Barretenberg and run over Noir circuits. A proof convinces a verifier that a private witness satisfies the circuit without revealing the witness itself.

The zero-knowledge property comes from blinding. The prover mixes fresh random values into the proof, so the output is statistically independent of the private inputs. Two proofs of the same fact differ, and neither carries a recoverable trace of the underlying data.

In the AffixIO build these proofs are generated with zero-knowledge enabled by default. The verifier learns only that the statement holds, which is why calling this path a zero-knowledge proof is accurate.

@affix-io/sdk-light with HMAC: not zero-knowledge

Affix Light binds a decision and its witness with HMAC-SHA256, keyed hashing standardised in FIPS 198-1 over SHA-256 from FIPS 180-4. An HMAC shows that a holder of a shared secret produced the tag and that the message was not altered. That is integrity and authenticity, not a proof about a hidden statement.

It hides nothing by construction, and it is symmetric. The verifier holds the same secret and could produce the same tag, so on its own it does not prove anything to a third party who was not given that secret. There is no blinding and no circuit.

Use it where a millisecond gate on a constrained host matters more than a standalone cryptographic proof. Do not call it zero-knowledge. On this path the third-party-checkable artefact is the ML-DSA-65 signature, not the HMAC.

Short version: zero-knowledge hides a witness while proving a statement about it, and HMAC authenticates a message with a shared key. The first is @affix-io/sdk. The second is @affix-io/sdk-light and is labelled as not a SNARK in the package source.

Limits

What AffixIO does not claim about NIST

Separating capability from marketing is most of a reviewer's job. Here is the separation, done in advance.

No FIPS 140-3 validation and no CMVP certificate. We do not operate a validated cryptographic module, and implementing a NIST-standardised algorithm is not a substitute for one. If your policy requires validation, we do not currently meet it.
No FedRAMP authorisation and no SP 800-53 assessment. No agency authorisation, no assessed control baseline and no third-party attestation against either.
No NIST CSF 2.0 profile and no SSDF attestation. Neither has been produced or assessed. The secure development gaps are listed in the table instead of being smoothed over.
No claim to run our own NIST test vectors. Correctness of the ML-DSA implementation rests on the library we depend on and its own testing. We have not built an independent known-answer test suite, and we will not imply that we have.
No key encapsulation claim. ML-KEM is not used. Any post-quantum protection of data in transit belongs to the transport layer, which sits outside this application and outside what we can evidence here.
No claim that every AffixIO proof is zero-knowledge. The circuit path is. The lightweight local scheme is a keyed message authentication code and is documented as such in the SDK source.
No claim that using AffixIO makes you compliant. Compliance is a property of your system and your assessment. A component cannot confer it, and any vendor telling you otherwise is selling something.

Direct answers

Short answers

For people, search engines and retrieval systems.

Is AffixIO NIST compliant? AffixIO implements NIST-standardised cryptography and holds no NIST validation or assessment. ML-DSA-65 under FIPS 204 signs every verification outcome and SHA-256 under FIPS 180-4 anchors the audit tree, both verifiable from public endpoints. There is no FIPS 140-3 certificate, no SP 800-53 control assessment and no CSF 2.0 profile. Compliance itself remains a property of your system rather than of a component inside it.

Which parameter set is used?

ML-DSA-65, targeting NIST security category 3. The published public key is 1952 bytes, which is the length FIPS 204 defines for that parameter set and the quickest way to confirm it.

Is FIPS 204 the same as FIPS 140-3?

No. FIPS 204 specifies an algorithm anyone may implement. FIPS 140-3 validates a specific module build through a laboratory and issues a certificate. AffixIO meets the first and not the second.

What are the transition dates?

The initial public draft of NIST IR 8547 describes deprecating 112-bit classical algorithms after 2030 and disallowing them after 2035. It remains a draft, so treat the dates as planning material.

Where is the weakest point?

Key custody. The signing key is a file on the host rather than in a hardware security module, and API keys are stored on disk in readable form. Both are named in the table.

Questions

Is AffixIO FIPS 140-3 validated?

No. AffixIO holds no CMVP certificate and does not operate a validated cryptographic module. It implements an algorithm that NIST standardised in FIPS 204, which is a different thing. FIPS 204 defines ML-DSA and anyone may implement it. FIPS 140-3 is a validation programme in which a laboratory tests a specific module build and NIST issues a numbered certificate. Any vendor claiming the second on the strength of the first is overstating its position.

Which NIST post-quantum standard does AffixIO use?

FIPS 204, the Module-Lattice-Based Digital Signature Standard, at the ML-DSA-65 parameter set. That parameter set targets NIST security category 3 and has a 1952-byte public key. You can confirm the parameter set yourself by measuring the published key, because FIPS 204 fixes that length.

Is ML-DSA the same as CRYSTALS-Dilithium?

They are closely related but not interchangeable. ML-DSA is the standardised form published in FIPS 204, and it differs from the original CRYSTALS-Dilithium submission in domain separation, parameter naming and signing details. Code written against a pre-standard Dilithium implementation will not necessarily verify a FIPS 204 signature.

When do RSA and elliptic curve signatures have to be retired?

The initial public draft of NIST IR 8547 sets out an expected approach in which classical algorithms at 112 bits of security, including RSA-2048 and ECDSA on P-256, are deprecated after 2030 and disallowed after 2035. It is a draft, the comment period has closed, and the dates are not final until the report is published. Plan against them rather than treating them as settled.

Does SHA-256 need to be replaced because of quantum computing?

No. NIST has not deprecated SHA-256. The quantum result usually cited is Grover's algorithm, which offers at best a quadratic speed-up on brute-force search and therefore reduces the margin rather than breaking the function. Symmetric primitives and hashes are in a very different position from RSA and elliptic curve cryptography, which Shor's algorithm attacks directly.

Does integrating AffixIO make our service NIST compliant?

No, and treat any vendor who says otherwise with suspicion. Compliance is a property of your system, your controls and your assessment, not of one component inside it. What AffixIO gives you is a signature scheme that already uses a standardised post-quantum algorithm, an audit trail you can verify independently, and a narrower data footprint to describe in your own documentation.

Where is the AffixIO signing key held?

The private key is held as a file readable by the service account, not in a hardware security module or a managed key service. The public half is published for offline verification. This is a real limitation of the current deployment and it is listed on this page rather than left for a reviewer to discover.

Can you complete our supplier assurance questionnaire?

Yes. Send it to hello@affix-io.com with the deployment you have in mind. Say whether a validated cryptographic module is a hard requirement, because that answer determines quickly whether the rest of the questionnaire is worth either side's time.