NCSC alignment
The National Cyber Security Centre sets the UK technical direction on post-quantum migration, zero trust and secure design. AffixIO is not NCSC certified and does not make you compliant. It is a verification component that already signs with ML-DSA-65, keeps personal data on your host through the SDKs, and exposes the same gates to agents through MCP. This page states the problem, the solution, where it works, and which NCSC publications we align with honestly.
Last reviewed against the running implementation and current NCSC guidance.
Position
AffixIO already signs eligibility outcomes with ML-DSA-65, so the attestation path is not sitting on the NCSC migration backlog for 2031 and 2035. Personal data stays on your host when you prove with @affix-io/sdk or @affix-io/sdk-light, and agents can call the same gates through the remote MCP server without receiving a customer dossier. What AffixIO does not give you is an NCSC certificate, a Cyber Essentials badge, a completed CAF assessment or a finished organisational PQC programme.
This page is planning material for security reviewers, not legal advice and not an NCSC endorsement. For NIST algorithm detail see the NIST alignment page. For US CISA guidance see CISA alignment.
Problem
They compound. Treating them as separate programmes is how organisations miss the 2028 discovery date.
Eligibility receipts signed with RSA or ECDSA today may still be relied on after classical public-key algorithms are deprecated. The NCSC PQC migration timelines set discovery and planning by 2028, highest-priority migration by 2031 and completion by 2035. Long-lived attestations become migration debt if they are issued on schemes that will not survive those dates.
Age gates, KYC and agent permission checks often ship names, dates of birth and document images to a vendor. That widens the breach surface, complicates DPIAs and works against the data minimisation outcomes many CAF and board-level reviews expect. The problem is architectural, not a policy memo.
NCSC zero trust architecture design principles assume the network is hostile and require every request to be authenticated and authorised against policy. A verification service that trusts callers by subnet, or that returns soft answers without a checkable record, does not help that model.
Solution
AffixIO is built around a binary eligibility outcome and a digests-first audit trail, not a copy of your customer.
Your host evaluates its own records and produces a proof. On the standard path AffixIO receives the proof and public inputs, not the underlying personal data. Document parsing helpers are the exception and are optional.
api.affix-io.com verifies the proof, returns allow or deny, and signs the outcome with ML-DSA-65. The digest is anchored in a SHA-256 Merkle audit tree so you can show inclusion later without replaying the person.
The same decision surface is available to agents through the remote MCP server. An agent requests a gate, AffixIO returns a signed yes or no, and the customer dossier never needs to leave your systems for that check.
Why AffixIO works
NCSC guidance is clear that PQC migration is a multi-year programme spanning investment cycles. The expensive part is usually not choosing an algorithm. It is finding every place a classical signature or key exchange still sits, including supplier products and long-lived roots of trust.
AffixIO attacks one of those places early. Verification outcomes are already signed with a NIST-standardised post-quantum scheme, so the eligibility receipts you keep are not items to re-issue when classical algorithms are deprecated. That does not finish your organisational migration. It means this component is already on the recommended side of the ledger.
The second reason it works for NCSC-shaped reviews is data shape. Design principles that tell you to make compromise difficult and to avoid concentrating sensitive data map cleanly onto a prove-locally model. AffixIO keeps digests and decisions, not dossiers, on the standard path. Reviewers can describe that split in a DPIA without inventing a story.
The third reason is checkability. Zero trust and CAF-style assurance both prefer evidence you can verify later. A published ML-DSA-65 public key, a Merkle root and a decision receipt give you that without asking a reviewer to trust a screenshot.
Where it works
Concrete places, not a generic platform claim.
Online Safety Act style age assurance, right-to-rent style checks and other binary gates where you need a signed outcome and a narrow data footprint. AffixIO carries the result. Choosing the method and evidencing effectiveness remain yours.
Prove against your own records or claim hashes, verify remotely, keep an audit leaf. Useful when a processor should not hold a second copy of identity documents.
Edge Audit style deployments keep subject records local and send only a subject reference and proof materials. That matches NCSC interest in reducing unnecessary data movement.
When an LLM or automation needs to know whether an action is allowed, MCP exposes AffixIO gates so the model receives a decision rather than raw personal fields.
SDKs and MCP
Three products, one decision model. Pick the prove path that matches latency and assurance needs.
Enterprise Node SDK for local prove with Noir circuits and UltraHonk. Personal data stays on your host. AffixIO verifies and can return an ML-DSA-65 attestation.
Millisecond local prove using Affix Light HMAC-SHA256 on Node crypto. Explicitly not UltraHonk and not a SNARK. Use when latency matters and the threat model accepts a keyed MAC.
Model Context Protocol access to AffixIO tools for agents and IDEs. Same API key auth, same policy surface, same digests-first evidence. Agents get allow or deny without a customer extract.
If a design needs AffixIO to hold your customer database to make onboarding easier, it is the wrong design for this product. Keep source records with you and send proofs.
Proof systems
Both SDKs prove locally, but they do not make the same cryptographic claim. This matters if you describe either as zero-knowledge in a bid or an assurance document.
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 do not match, and neither carries 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 calling this path a zero-knowledge proof is accurate.
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 afterwards. 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 artefact a third party can rely on is the ML-DSA-65 attestation, 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 fits @affix-io/sdk. The second is @affix-io/sdk-light and is labelled as not a SNARK in the package source.
Alignment
Filter by status. Detail describes the running implementation, not a roadmap slide.
Showing all 16 publications
| Publication | Status | What the implementation actually does |
|---|---|---|
| PQC migration timelines2028 / 2031 / 2035 | Implemented | The AffixIO attestation path already uses ML-DSA-65. For this component there is no classical signature left to migrate. Your wider estate discovery, supplier plans and 2035 completion remain organisational work AffixIO cannot finish for you. |
| ML-DSA / FIPS 204Recommended PQC signature | Implemented | Every verification outcome is signed with ML-DSA-65. The public key is published at /.well-known/affix-mldsa65.json and measures 1952 bytes. See also the NIST page for the algorithm versus validation distinction. |
| Cyber security design principlesMake compromise difficult | Implemented | On the standard path AffixIO does not hold identity dossiers, so a compromise of AffixIO does not yield your customer database. Proofs, digests and decisions are the retained artefacts. Optional parsing helpers are the documented exception. |
| Setting direction for UK PQCMarch 2025 blog | Aligned | Early migration of a high-value evidence path matches the NCSC call to start now rather than wait for a rushed 2030s cutover. AffixIO is one supplier product you can already put on the post-quantum side of a discovery inventory. |
| Zero trust design principlesAuthenticate and authorise everywhere | Aligned | Every API call authenticates on its own merits with a bearer key and is rate limited. Network position grants nothing. AffixIO does not implement your whole zero trust architecture; it fits the per-request authorisation model for eligibility decisions. |
| Secure development guidanceDevelopers collection | Aligned | Circuit templates, pinned lockfiles and integration tests sit on the proving path. Gaps remain on SBOM publication and automated dependency scanning, listed under limits rather than hidden. |
| Cloud security principlesShared responsibility | Aligned | AffixIO is designed so customers keep source identity data and AffixIO handles proof verification. That split matches a clear shared-responsibility story for cloud-hosted verification. |
| Using TLS to protect dataData in transit | Aligned | Public AffixIO endpoints are served over TLS at the edge. The application process itself listens locally behind that edge. Transit protection is a deployment property, not something reinvented inside the prove API. |
| Cyber Assessment FrameworkCAF outcomes | Partial | AffixIO can support data minimisation and assurance-of-decision evidence inside a CAF programme. It is not a CAF assessment, not an NCSC-assured assessment service and not a substitute for organisational risk management. |
| Zero trust collectionFull architecture | Partial | Per-request auth and policy gates for eligibility are in place. Continuous device posture, enterprise SSO integration and organisation-wide policy engines are outside AffixIO and remain yours to assemble. |
| Password guidanceAuthenticators | Partial | Hub passwords use scrypt with a per-user salt and constant-time compare. API keys are long random bearer tokens stored on disk in readable form, which is a gap reviewers should know about. Prefer short-lived keys and rotation through Hub. |
| Secure development principlesSupply chain hygiene | Partial | Dependencies are locked and circuit templates are integration-tested. There is no published SBOM, no CI dependency scanning in the trees reviewed for this page and no signed release artefact programme. |
| Device security guidanceEndpoint hardening | Not used | AffixIO is a verification API and SDK, not an endpoint management product. Device health signals are not part of the AffixIO decision engine today. |
| Cyber EssentialsBaseline scheme | Not claimed | No Cyber Essentials or Cyber Essentials Plus certificate is published for AffixIO on this site. Ask if you need the current status for procurement. |
| NCSC assured servicesAssured supplier lists | Not claimed | AffixIO does not claim to be an NCSC assured service for consultancy, incident response, CAPSS or any other NCSC assurance scheme. |
| Full organisational PQC programme2035 completion | Not claimed | Using AffixIO does not complete your migration. Inventory, ICS, long-lived hardware roots of trust, TLS stacks and supplier products still need your plan. |
No publications match that status.
Evidence
The PQC claim on this page does not require trusting the page.
_building_in_London.png){kind=link}
curl -s https://api.affix-io.com/.well-known/affix-mldsa65.jsonReturns "algorithm": "ML-DSA-65" with the public key.
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, the FIPS 204 length for ML-DSA-65.
curl -s https://api.affix-io.com/v1/merkle/rootReturns root, leaf_count and updated_at.
Limits
Direct answers
Does AffixIO align with NCSC guidance? AffixIO implements ML-DSA-65 on the attestation path, keeps personal data on the customer host for standard proves via the SDKs, and authenticates every API request. It holds no NCSC certification, no Cyber Essentials badge on this site and does not complete an organisational CAF or PQC programme.
Long-lived eligibility evidence signed with classical algorithms, and verification designs that copy personal data to a vendor.
Prove locally with @affix-io/sdk or @affix-io/sdk-light, verify on api.affix-io.com, attest with ML-DSA-65, anchor digests, optionally gate agents through MCP.
Age and eligibility gates, KYC-style checks, edge audits and agent tool permission decisions.
This component is already post-quantum on signatures. Your discovery plan, priority migrations and full estate completion remain organisational work.
No. The NCSC publishes technical guidance; it does not certify AffixIO and AffixIO does not certify you. Compliance is a property of your organisation, your controls and your assessment. AffixIO is a component that can reduce cryptographic migration debt and keep personal data off a third-party verification path.
AffixIO already signs verification outcomes with ML-DSA-65 under FIPS 204, so the attestation path is not a future migration item. That supports early, highest-priority migration of eligibility evidence. Discovery of your wider estate, supplier engagement and full organisational migration by 2035 remain your programme.
No. AffixIO does not currently publish a Cyber Essentials or Cyber Essentials Plus certificate. Ask for the current status if that is a procurement gate.
@affix-io/sdk proves locally with Noir and UltraHonk so personal data stays on your host. @affix-io/sdk-light proves locally with Affix Light HMAC-SHA256 for millisecond gates and is not a zero-knowledge proof. The remote MCP server exposes AffixIO tools to agents under the same API key and policy controls, so an agent can request an eligibility decision without shipping a customer dossier.
No. The Cyber Assessment Framework is an organisational assessment of how you manage risk to essential functions. AffixIO can support specific outcomes such as data minimisation and assurance of decisions, but it is not a CAF assessment and is not an NCSC-assured consultancy product.