Built-in Standards Catalogue
The policy baselines shipped with CBOM Secure: what each one permits, what it is derived from, and how to use it. Read this alongside the Standard Policy page, which covers the interface, and Risk and PQC Scoring, which covers how a Pass or Fail is decided.
What a standard policy is
A standard policy is a read-only baseline: a named list of algorithm references that the policy permits. Evaluating a material against it gives a discrete Pass or Fail — Pass if the material's algorithm reference appears in the allowed list, Fail otherwise.
| Property | Behaviour |
|---|---|
| Editable | No. Clone a baseline to obtain an editable user policy. |
| Management | Creating, updating and deleting baselines requires the administrator role. |
| Evaluation unit | One material against one policy. |
| Outcome | Pass or Fail. There is no partial result. |
These baselines are post-quantum migration baselines, not full compliance rule sets. Each one lists the algorithms that are acceptable as a migration target under the named standard. None of them encodes the wider control set of the standard it is named after — key management practice, logging, access control, audit evidence. Passing a baseline means an algorithm is on that standard's approved list; it does not by itself mean an organisation is compliant with the standard.
The baselines
Post-quantum migration baseline
The majority of the shipped baselines permit the same set: AES-256 plus the NIST-selected post-quantum families and the stateful hash-based signature schemes.
Permitted algorithm references
AES/256
ML-DSA/44 ML-DSA/65 ML-DSA/87
ML-KEM/512 ML-KEM/768 ML-KEM/1024
SLH-DSA
HQC/128 HQC/192 HQC/256
LMS/SHA192 LMS/SHA256 LMS/SHAKE192 LMS/SHAKE256
HSS/SHA192 HSS/SHA256 HSS/SHAKE192 HSS/SHAKE256
XMSS/SHA192 XMSS/SHA256 XMSS/SHAKE192 XMSS/SHAKE256
XMSST/SHA192 XMSST/SHA256 XMSST/SHAKE192 XMSST/SHAKE256The baselines carrying this list:
| Baseline | Named after | Note |
|---|---|---|
NIST-SP-800 | NIST SP 800 series | The reference list; the others are aligned to it. |
FIPS | FIPS 203, 204 and 205 | ML-KEM, ML-DSA and SLH-DSA respectively. |
PCI-DSS | PCI Security Standards Council payment card standard | Applied to cardholder data protection. |
GDPR | EU General Data Protection Regulation, Article 32 | GDPR mandates no specific algorithm; the baseline expresses the migration target for the security-of-processing obligation. |
HIPAA | US HIPAA Security Rule | HIPAA mandates no specific algorithm; the baseline expresses the migration target for protecting electronic protected health information. |
ISO | ISO/IEC JTC 1/SC 27 WG 2 | ISO post-quantum standards are still in development; this tracks the expected target. |
CIS | CIS Controls | |
CMMC / CMMC-2.0 | Cybersecurity Maturity Model Certification | |
NSM-10 | US National Security Memorandum 10 | |
IL5+/FedRAMP | US federal impact level 5 and FedRAMP | |
SG-MAS | Monetary Authority of Singapore | Reflects MAS Circular MAS/TCRS/2024/01, which directs financial institutions to inventory cryptographic assets and migrate critical ones to quantum-resistant algorithms. |
Where a standard does not itself mandate algorithms, the baseline states a migration target. GDPR, HIPAA and several others impose an obligation to protect data without naming a cipher. The baseline named after such a standard expresses what CBOM Secure treats as an acceptable post-quantum target for that obligation — it is a defensible starting point, not a quotation from the regulation. Review it against your own legal advice before using it as evidence.
Baselines with their own algorithm list
Five baselines differ from the list above because the standard they follow names a narrower set.
CNSA-2.0 — Commercial National Security Algorithm Suite 2.0
The US National Security Agency's algorithm suite for National Security Systems. Markedly narrower than the general baseline: one parameter set per family, at the highest security level.
AES/256
ML-DSA/87
ML-KEM/1024
LMS/SHA192 LMS/SHA256
XMSS/SHA192 XMSS/SHA256ASD — Australian Signals Directorate
Derived from ISM control 1917. Retains RSA-4096 alongside the post-quantum algorithms, reflecting a transition period rather than a completed migration.
ML-DSA/87
AES/256
RSA/4096ISM-1917 — ASD ISM control 1917
Transitioning to post-quantum cryptography. New cryptographic equipment and software being developed or procured must support the listed algorithms by 2030. Applies across Non-Classified, Official, Protected, Secret and Top Secret. Updated December 2024.
ML-DSA/44 ML-DSA/65 ML-DSA/87
ML-KEM/512 ML-KEM/768 ML-KEM/1024ISM-1990 — ASD ISM control 1990
Asymmetric algorithm control, following FIPS 203 and FIPS 204, with AES-256 for symmetric use.
AES/256
ML-DSA/44 ML-DSA/65 ML-DSA/87
ML-KEM/512 ML-KEM/768 ML-KEM/1024ISM-1769 — ASD ISM control 1769
Symmetric algorithm control. Permits all three AES key lengths, so it is the only shipped baseline under which AES-128 passes.
AES/256 AES/192 AES/128Source for the three ISM controls: the ASD Information Security Manual cryptography guidelines, published at cyber.gov.au.
Reading a Pass or Fail
A material Passes a policy when its algorithm reference is in that policy's allowed list, and Fails otherwise. Three consequences follow, and all three surprise people the first time:
A strong classical algorithm Fails the post-quantum baselines. RSA-4096 is rated Low rather than Critical on the criticality scale — it is sound today — but it is absent from every baseline except
ASD, so it Fails them. That is the intended reading: the baselines state a migration target, not a judgement of present strength.AES-128 Fails everywhere except
ISM-1769. It is rated Critical on the criticality scale and is absent from the other allowed lists.A material whose algorithm cannot be resolved is not silently passed. Policy evaluation and criticality scoring both work from the same resolved algorithm reference; a material whose algorithm is not in the ranking tables reports No Analysis for criticality, and a policy cannot admit an algorithm it cannot name.
Policy conformance is reportable as a current snapshot and as a time series, so a migration can be evidenced as a trend rather than a single figure.
Using a baseline
Open Governance → Standard Policy and review the baseline's allowed list.
Clone it into a user policy if you need to change anything — add a transitional algorithm, tighten a parameter set, or restrict it further.
Evaluate your inventory against it from the policy analysis widgets, and drill into the failing material.
Track conformance over time as the migration proceeds.
Baselines are versioned data rather than code, so they can be updated as the standards they follow are revised, without a product upgrade.
Check the shipped baselines before relying on them for reporting. Confirm that each baseline's allowed list matches your own reading of the standard, and remove any baseline you do not intend to report against. A baseline that carries a name your auditors recognise will be read as authoritative, so it is worth reviewing once rather than assuming.