Quantum Readiness Assessment v0.1 - markdown-first draft of the Track 1 deliverable

[m-khan-97]

Volunteering to build and maintain the Quantum Readiness Assessment - the
charter Track 1 deliverable alongside the Top 10: "an open-source Quantum
Readiness Assessment Assistant so the Top 10 becomes operational rather than
purely descriptive." Markdown-first, following the precedent set by the
knowledgebase: useful today, tool later.

What v0.1 contains

• Seven scored domains mapping to QS01-QS07: data exposure and lifetimes,
  signatures and trust anchors, inventory/CBOM, crypto-agility, migration and
  hybrid deployment, hardware roots of trust, and programme integrity (does the
  programme measure algorithms retired, or budget spent?).
• A deadline matrix built only from published anchors - NCSC 2028/2031/2035,
  EU end-2026 / end-2030, CNSA 2.0 2030/2033, the CA/Browser Forum 47-day
  lifetime, and NIST IR 8547 explicitly marked as draft.
• A Mosca worksheet (X + Y > Z) as the prioritisation frame, with findings
  ranked by deadline proximity and Mosca margin rather than sensitivity labels.
• A findings template where every gap links back to the QS entry it derives
  from, so the assessment and the Top 10 stay coupled as entries evolve.
• A scoring rule that treats "Unknown" as a finding - an Unknown in any
  domain is an inventory gap (QS04) by definition.

Design decisions open to challenge

• Migration surface only for now. A platform-surface extension (QS08-QS10)
  should follow once Sprint 1 voting stabilises those entries.
• Questions are phrased to be answerable in a one-workshop first pass; where a
  question's premise conflicts with an entry as it evolves, the entry wins.
• Placed under tooling/assessment/ to slot into the directory proposed in
  Add tooling directory for community-built tools, per Slack discussion #33; the two PRs touch different files, so they merge in either order. If the
  leads prefer a top-level assessment/, happy to move it.

I commit to maintaining this through the sprint cycle: updating questions as
entries change through v0.2-v0.6, and building it out into the assistant tool
proper after v1 publication.

[nmcitra]

This is more finished than most first drafts. The deadline matrix is the part I'd point people at: built only from published anchors, dated, and it marks IR 8547 as draft rather than citing it as settled. That's what makes a self-assessment defensible when someone senior asks where a number came from.

Two structural notes, then smaller ones.

Domain D measures whether you can change the algorithm, not whether trust survives the change.

D1 through D5 are all replaceability: abstraction, library versions, rotation rehearsal, procurement, symmetric review. Each is right, and D3 is the strongest question in the set because it makes people prove it rather than assert it.

What isn't asked anywhere is what happens to everything bound to the credential when the credential is replaced. Re-issue a certificate for the same subject and the entitlements, delegated permissions, service-mesh identities, cached authorization decisions, and long-lived sessions attached to the old key tend to carry forward untouched. The rotation succeeds, the estate is agile, and nobody re-established why any of those bindings should still hold.

For machine and workload identities that's most of the population, and there's no NIST assurance framework covering them the way SP 800-63 covers people. 800-63-4 excludes them in its own words — "these guidelines do not explicitly address some subjects including, but not limited to, machine-to-machine authentication, interconnected devices... or access to Application Programming Interfaces," and "for this publication, 'person' refers only to natural persons."

Full disclosure: this failure mode is the subject of my own entry (#31), so discount my enthusiasm accordingly. The questions stand or fall on Domain D's own logic.

#	Question
D6	When a credential is re-issued during migration, is the authorization state bound to it (roles, entitlements, delegations, cached decisions, active sessions) explicitly re-established, rather than carried forward on subject continuity alone?
D7	For machine, workload, and service identities, is the proofing required to re-enrol at migration defined and documented?
D8	Does the rehearsal in D3 include a re-enrolment where the old credential is treated as untrusted, rather than one where it's available to authorise its own replacement?

D8 is the one I'd most want in there. A rotation rehearsed with the old key present tests the mechanics but not the failure mode, and the failure mode is what deadline pressure will produce. F2 has the same seam: it asks whether the update path has been tested, which is the right question, but a fleet whose anchor was re-provisioned using the current anchor hasn't tested the case where that anchor is the thing you've lost confidence in. Might be worth one pass across both.

There's no domain for identity itself. A through G cover data, signatures, inventory, agility, migration, hardware, and programme. Identity and authorization appear only as consequences of those. That may be deliberate and I'm happy to be told it is — but if the assessment is meant to make the Top 10 operational, the population being migrated is mostly non-person entities, and they don't have a home here.

Smaller things:

• B2 (verifier populations that can't be upgraded) is the best question in Domain B. Unupgradeable verifiers are what turn a migration into a permanent hybrid.
• C3 asking for custody, rotation, and a named owner rather than just algorithm and length is the difference between an inventory and a spreadsheet.
• E2 (monitor the negotiated group, alert on classical-only) is the one most organisations will fail without knowing they're failing.
• B5 already forces the 47-day automation answer; worth a cross-reference from Domain D, since anyone failing B5 has answered D3 in the negative, whatever they say.

Happy to draft D6–D8 properly as a PR against your branch if that's easier than folding comments in. Your structure, your call.