AffixIO logoAffixIO
Request Access

CISA alignment

Which CISA guidance AffixIO implements, and which it does not.

CISA is the US Cybersecurity and Infrastructure Security Agency. This page uses /csia/ because that spelling appears in searches, but its primary subject is current CISA guidance. The historical UK Central Sponsor for Information Assurance, also called CSIA, was absorbed into organisations that became today's National Cyber Security Centre.

AffixIO can support Secure by Design, Zero Trust and quantum readiness work as one product component. It is not CISA certified, it has no FedRAMP authorisation, and it does not make a customer's programme compliant.

Read the alignment tableVerify it yourself

Last reviewed against the running implementation. Written for US security reviewers, critical infrastructure teams and procurement leads.

United States Department of Homeland Security building viewed from outside
CISA sits within the US Department of Homeland Security. DHS building photograph by DHSgov, public domain as a US Federal Government work.

Position

A component for a wider security programme

AffixIO is a UK verification product that can support US customers applying CISA guidance. Its strongest alignment is concrete: local proof generation reduces exposed identity data, each API request is authenticated, verification outcomes use ML-DSA-65 post-quantum signatures, and SHA-256 Merkle records provide independently checkable audit evidence. CISA guidance is programme-level. AffixIO does not replace governance, network controls, device posture, incident response, procurement assessment or an organisation's own compliance work.

Product role
Verification and signed eligibility decisions.
Strongest alignment
Secure by Design data minimisation and quantum-ready attestations.
Programme coverage
Partial. Not a complete Zero Trust or critical infrastructure programme.
Agency status
No CISA certification, endorsement or filed federal attestation.

CISA does not provide a general product certification represented by this page. Status labels below describe the AffixIO implementation against named guidance, not an agency finding.

Problem and response

Reduce what can be taken, then preserve evidence

CISA's Secure by Design guidance puts responsibility on technology providers. AffixIO's contribution is deliberately narrow.

Problem

Eligibility checks often copy identity attributes into another vendor system. That creates another store of names, documents and dates of birth, then asks access controls and retention policy to contain the new risk.

Solution

Generate the proof on infrastructure the customer controls. Send AffixIO the proof, public inputs and digests. Receive a granular allow or deny outcome with a post-quantum signature and an audit anchor.

Why AffixIO works

The control is architectural rather than a promise about later deletion. Identity remains with the customer on the standard path, each request requires a key, and evidence can be checked without asking AffixIO to confirm its own claim.

Deployment surfaces

Where the control sits

Choose the proving and access path that matches the assurance requirement. The two SDKs do not make the same cryptographic claim.

Customer-controlled proving

Personal attributes can stay on the customer's host while the proof is produced. AffixIO receives proof material and public inputs rather than an identity warehouse.

Remote verification and tools

The API verifies, signs and anchors outcomes. The remote MCP server exposes API-backed MCP tools for authorised agent and automation clients.

@affix-io/sdk

Runs UltraHonk and Noir proving locally. This is the zero-knowledge route for keeping witness values inside the customer's environment.

  • npm package
  • Local prove, remote verify
  • Use for stronger disclosure minimisation

@affix-io/sdk-light

Affix Light uses HMAC for a smaller local integration. It is not a zero-knowledge proof and must not be described as one.

  • npm package
  • HMAC-based integrity
  • Different assurance boundary

MCP and API

The remote MCP service and API MCP tools let authorised clients call AffixIO capabilities through a defined interface. The same product boundaries and customer responsibilities still apply.

  • Product surface
  • Per-request API authentication
  • Remote service, not local identity custody

Proof systems

Why one path is zero-knowledge and the other is not

Both SDKs prove locally, but they do not make the same cryptographic claim. The distinction matters if you cite zero-knowledge in an attestation, a SBOM narrative or a Secure by Design statement.

@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 leaks a recoverable trace of the data behind it.

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 describing this path as 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. An HMAC is a keyed message authentication code. It shows that someone holding 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 for external use: 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.

Alignment

Sixteen CISA-relevant items, each with a status

Filter the table by status. Implementation statements describe the running product as reviewed on 14 August 2026.

AffixIO alignment with CISA guidance and related US federal security expectations, reviewed 14 August 2026.
Guidance or controlStatusWhat the implementation actually does
NIST FIPS 204ML-DSA-65 attestationImplementedEvery verification outcome is signed with ML-DSA-65. The public key is published for offline verification. This is an algorithm implementation, not FIPS 140-3 validation and not a CISA certification.
Audit integritySHA-256 digests and Merkle anchoringImplementedSHA-256 produces signed payload digests and domain-separated leaf and node hashes in the Merkle audit tree. The current root and leaf count are available from a public endpoint.
Authenticated service accessPer-request API key checksImplementedAPI requests are authenticated individually with a customer key and rate limited per key. Network location alone does not grant access.
CISA Secure by DesignCustomer security outcomesAlignedThe normal integration keeps personal attributes on customer-controlled infrastructure and sends proof material instead. This supports a safer default data path, but does not represent adoption of every Secure by Design principle.
Secure by Design pledge themesMinimise customer security burdenAlignedLocal proving reduces the identity data placed in a vendor system. Public verification material lets customers test signature and audit claims directly rather than relying only on supplier statements.
CISA quantum readinessVendor and cryptographic inventory readinessAlignedThe attestation path already uses ML-DSA-65, so it carries no RSA or elliptic curve signature migration for that function. Customers still need their own cryptographic inventory and migration plan across every other component.
Harvest now, decrypt later planningLong-lived cryptographic exposureAlignedAffixIO addresses the related long-lived signature risk by issuing post-quantum attestations now. It does not claim post-quantum transport encryption, and the application does not implement ML-KEM.
Data minimisationNo central PII warehouse on standard pathAlignedWith the UltraHonk and Noir SDK path, witness values remain with the customer. AffixIO retains digests and decision evidence, not a copied identity record. Parsing helper endpoints are a separate data path described on the compliance page.
Zero Trust Maturity ModelApplications and Workloads pillarPartialPer-request authentication and granular eligibility decisions support application-level policy enforcement. AffixIO does not provide continuous device posture, enterprise identity orchestration or a complete ZTMM programme.
Zero Trust Maturity Model v2Data pillarPartialLocal proof generation and digest-based audit reduce centralised identity exposure. Data classification, discovery, enterprise rights management and organisation-wide loss prevention remain outside the product.
Secure software developmentNIST SSDF-related practicePartialDependencies are pinned in a lockfile and the proving path has integration tests. There is no SBOM, no automated dependency scanning in continuous integration and no signed release artefact.
Cryptographic key custodySigning key protection and rotationPartialAttestations identify the signing key and the public half is published. The private key is held as a file readable by the service account, not in an HSM or managed key service, and rotation is not on a fixed cryptoperiod.
Post-quantum key establishmentML-KEM and transport encryptionNot usedThe AffixIO application performs no key establishment of its own and does not use ML-KEM. Transport-layer cryptography is outside the application claim made on this page.
CISA product certificationAgency approval or endorsementNot claimedCISA has not certified, approved or endorsed AffixIO. This is a supplier-authored alignment page against public guidance.
Federal software attestationCISA Secure Software Development Attestation FormNot claimedAffixIO has not filed the Common Form for federal software attestation. Partial SSDF-related practices do not amount to a filed attestation.
Federal authorisation and validationFedRAMP and FIPS 140-3Not claimedThere is no FedRAMP authorisation, no validated cryptographic module and no FIPS 140-3 certificate. See the detailed NIST alignment page.
  • ImplementedThe control runs in the product today and can be observed or tested.
  • AlignedThe architecture supports the guidance, without implying formal assessment.
  • PartialPart is present and the missing programme or technical scope is stated.
  • Not usedThe technology is outside the application or unnecessary for this function.
  • Not claimedA certification, filing, authorisation or validation AffixIO does not hold.

Evidence

Check the cryptographic claims yourself

The signature scheme and audit root are available from public endpoints. No AffixIO credential is needed.

  1. Read the published signing key

    The response identifies the algorithm and includes the public key.

    curl -s https://api.affix-io.com/.well-known/affix-mldsa65.json

    Returns "algorithm": "ML-DSA-65" with the public key and publication time.

  2. Confirm the ML-DSA-65 key length

    FIPS 204 fixes the ML-DSA-65 public key at 1952 bytes.

    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.

  3. Derive the attestation key identifier

    The identifier connects a stored attestation to the published key.

    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])"

    The value changes when the signing key is rotated.

  4. Read the current Merkle root

    The public root anchors the digest-based audit tree.

    curl -s https://api.affix-io.com/v1/merkle/root

    Returns root, leaf_count and updated_at.

These checks establish implementation facts. They do not establish CISA certification, federal authorisation or cryptographic module validation.

Limits

What AffixIO does not claim

These boundaries are part of the product position, not footnotes.

  • No CISA certification or endorsement.CISA has not assessed, certified, approved or endorsed AffixIO.
  • No FedRAMP authorisation.AffixIO has not entered or completed a FedRAMP authorisation process.
  • No filed Secure Software Development Attestation Form.AffixIO has not filed the federal Common Form. A pinned lockfile and integration tests are not a substitute.
  • No FIPS 140-3 validation.ML-DSA-65 is implemented under the FIPS 204 algorithm standard. The software is not a validated cryptographic module.
  • No complete Zero Trust Maturity Model programme.AffixIO supplies application and data controls. It does not operate the customer's identity, device, network, workload and visibility programme.
  • No hardware-backed key custody.The signing key is held in a file readable by the service account, not an HSM or managed key service.
  • No claim that every proof is zero-knowledge.@affix-io/sdk uses UltraHonk and Noir local proving. Affix Light in @affix-io/sdk-light is HMAC-based and is not ZK.
  • No claim that integration creates compliance.AffixIO can support a customer's CISA-aligned programme as one component. Compliance remains the customer's programme and decision.
  • No ISO 27001 or SOC 2 claim.AffixIO holds neither and does not imply otherwise.

Direct answers

Short answers

Concise answers for reviewers and retrieval systems.

Is AffixIO CISA compliant? CISA guidance applies across an organisation's programme, not as a general product badge. AffixIO is a UK component that supports parts of Secure by Design, Zero Trust and quantum readiness through local proving, per-request authentication, ML-DSA-65 attestations and SHA-256 Merkle evidence. It is not CISA certified, FedRAMP authorised or a substitute for the customer's compliance programme.

Why does the URL say CSIA?

The /csia/ path captures a spelling found in searches. The living US agency discussed here is CISA. Historical UK CSIA responsibilities ultimately sit with today's NCSC.

What supports Secure by Design?

On the standard path, identity attributes remain with the customer while AffixIO receives proof material and digests. That reduces the data a supplier must protect.

What supports quantum readiness?

Verification outcomes are signed with ML-DSA-65 today. The claim covers signatures, not transport encryption, ML-KEM or the customer's wider cryptographic estate.

What is the largest gap?

Programme coverage and key custody. AffixIO is not a full Zero Trust programme, and its signing key is file-based rather than hardware-backed.

Questions

Direct answers on CISA, CSIA, federal claims and implementation boundaries.

Is AffixIO certified by CISA?

No. CISA has not certified AffixIO. This page maps product behaviour to published CISA guidance and identifies gaps. It is not an endorsement, certification or agency assessment.

Does AffixIO have FedRAMP authorisation?

No. AffixIO has no FedRAMP authorisation and makes no claim that it does.

Has AffixIO filed the CISA Secure Software Development Attestation Form?

No. AffixIO has not filed the federal Secure Software Development Attestation Form. Some development practices align partly with SSDF, but that is not a filed federal attestation.

How does AffixIO support CISA quantum readiness guidance?

Verification outcomes are already signed with ML-DSA-65, the post-quantum signature algorithm standardised by NIST in FIPS 204. This removes a classical signature migration from that path, but it does not make the whole customer system quantum ready.

Does AffixIO implement the CISA Zero Trust Maturity Model?

Only partly. Per-request API key checks, granular eligibility decisions and local proof generation support parts of the Applications and Workloads and Data pillars. AffixIO does not provide a complete Zero Trust Maturity Model programme.

Does using AffixIO make an organisation CISA compliant?

No. AffixIO is one UK product component that can support a US customer's CISA-aligned programme. Governance, architecture, controls, evidence and compliance decisions remain with the customer.

Why is the page path csia rather than cisa?

The path uses csia because that spelling appears in searches. The living US authority discussed here is CISA, the Cybersecurity and Infrastructure Security Agency. The historical UK Central Sponsor for Information Assurance was absorbed into organisations that became today's NCSC.

Is AffixIO FIPS 140-3 validated?

No. AffixIO implements ML-DSA-65 as standardised in FIPS 204, but holds no FIPS 140-3 cryptographic module validation. An algorithm standard and module validation are different claims.