A cryptographic inventory that lists assets without judging them is a spreadsheet with good intentions. You can sort it, filter it, and admire its completeness, but it does not tell you what to do, because every asset sits there with equal weight and no verdict. The moment anyone asks which of these violate our standards, or which of these should we fix first, a plain inventory goes quiet. The answers require the inventory to evaluate itself against rules and to score its own findings, and that evaluation is a distinct capability layered on top of discovery and classification.
Evaluation has three parts that work together. A policy engine encodes the rules the organization has decided to enforce and checks every asset against them. A standards-mapping layer connects those checks to external baselines and mandates so that compliance is demonstrable, not just asserted. And a risk-scoring model weighs findings by more than algorithm weakness alone, so that the output is an ordered set of priorities rather than an undifferentiated pile of violations. Together they convert an inventory into a worklist.
This post explains each of those three parts, why risk has to be multi-factor to be useful, and how the combination lets a team work in priority order instead of drowning in findings.
Compliance Gap: Required vs. Actual Certificate Coverage
What frameworks require vs. what organizations typically demonstrate
The average enterprise demonstrates 35% certificate coverage against framework requirements that expect 85-95%. This gap is where audit findings live.
The Policy Engine: Encoding What Good Looks Like
A policy engine is the component that holds the organization’s definition of acceptable cryptography and tests every asset against it. The point is to make the standard explicit and enforceable rather than tribal knowledge that lives in a few people’s heads and gets applied inconsistently. A policy that exists only as an understanding cannot be checked across ten thousand assets; a policy encoded as rules can be checked continuously and uniformly.
The rules a mature engine supports span the dimensions that actually define cryptographic hygiene:
| Policy Dimension | Example Rule |
|---|---|
| Approved algorithms | Only these signature and encryption algorithms are permitted |
| Minimum key sizes | RSA keys must be at least a stated length; symmetric keys at least a stated strength |
| Approved curves | Only these named elliptic curves are allowed |
| Certificate lifetime | Certificates may not exceed a maximum validity period |
| Permitted CAs | Certificates must be issued by an approved issuer |
| Allowed trust anchors | Only these roots may terminate a chain |
| Approved protocols | Only these protocol versions and configurations are allowed |
| Deprecated mechanisms | These algorithms and protocols are forbidden and must be flagged |
The requirement that makes this a real capability rather than a fixed checklist is configurability. Every organization’s policy differs, because it reflects that organization’s risk tolerance, regulatory environment, and legacy constraints. A bank’s minimum key sizes and a startup’s are not the same, and neither should be forced into a vendor’s opinion of what the rule ought to be. A configurable engine lets the organization express its own policy, including the uncomfortable exceptions it has chosen to live with, and then holds the estate to that policy consistently. An engine with hard-coded rules either overstates violations against a stricter standard than the organization adopted or understates them against a looser one.
Standards Mapping: Making Compliance Demonstrable
A policy engine checks the organization against its own rules. Standards mapping connects those rules to the external baselines the organization is measured against, so that passing the policy means something to an auditor, a regulator, or a customer. This is the difference between asserting compliance and demonstrating it: the former is a claim, the latter is a mapping from each requirement to the inventory evidence that satisfies or fails it.
The baselines a mature platform maps against cover the major cryptographic standards and mandates:
| Standard or Baseline | Scope |
|---|---|
| NIST SP 800-131A | Transitions for key lengths and algorithm strengths |
| NIST IR 8413 | Post-quantum algorithm selection context |
| CNSA 2.0 | National security suite, including post-quantum requirements and timelines |
| FIPS 140-3 | Validated cryptographic module requirements |
| PCI DSS 4.0 | Cardholder-data cryptography requirements |
Mapping is not only about public standards. Most enterprises run a certificate policy and certification practice statement that codify their own PKI rules, and many operate under sector baselines specific to their industry. A platform that maps only to public standards and cannot accommodate an organization’s own CP and CPS, or a sector-specific baseline, forces the organization to track its most binding rules outside the tool. Full standards mapping treats the external public standards and the organization’s own governing documents as peers, both expressible as policy and both reported against.
The value of the mapping is that it turns a question like “are we compliant with the key-length transition guidance” into a query with a concrete answer: these assets conform, these do not, and here is each nonconforming asset and the specific rule it breaks. Compliance stops being a periodic manual assessment and becomes a continuous property of the inventory.
Multi-Factor Risk Scoring: Beyond Algorithm Weakness
The third part is scoring, and it is the part most often done badly. A naive risk model scores an asset on the strength of its algorithm alone: weak algorithm, high risk; strong algorithm, low risk. That model is wrong in both directions. It over-alarms on a weak algorithm protecting something trivial and internal, and it under-alarms on a strong algorithm in a role whose compromise would be catastrophic. Risk is a property of the asset in its context, not of the algorithm in the abstract, and a useful score reflects that.
A multi-factor model weighs several independent factors:
- Algorithm weakness. The baseline: how broken or deprecated the cryptography is, including quantum vulnerability.
- Exposure. Whether the asset is externally reachable or confined to an internal network.
- Business criticality. The importance of what the asset protects, from a core revenue or safety system down to a low-stakes internal tool.
- Trust role. Whether the asset is a trust anchor whose compromise cascades, or a leaf whose compromise is contained.
- Key length. The specific parameters, which modulate the algorithm-weakness factor.
- Validity period. How long a compromised credential would remain trusted and exploitable.
- Known vulnerabilities. Whether the specific algorithm, parameters, or implementation carry documented weaknesses.
- Ease of remediation. How hard the asset is to fix, which affects where it sits in a priority order even when its intrinsic risk is high.
The reason to combine these rather than lead with algorithm strength is that the dangerous assets are usually the ones a single-factor model misranks. A trust anchor using a currently strong algorithm still carries enormous risk because of its role; a deprecated algorithm on an isolated, low-value, internal service may be a genuinely low priority despite its weakness. Ease of remediation belongs in the score for a practical reason: two assets of equal intrinsic risk are not equal priorities if one is a config change and the other is a hardware refresh, and a score that ignores remediation effort produces a worklist no one can execute in order.
Working in Priority Order
The purpose of all three parts together is to let a team work on the right things first. Discovery and classification tell you what you have. Policy evaluation tells you what violates the rules. Standards mapping tells you which violations matter to your obligations. Risk scoring tells you, among everything that violates something, what to do first. Without the last step, an organization faced with thousands of policy violations has no principled way to start and tends either to freeze or to work on whatever is most visible rather than most important.
A risk score that reflects business context changes that dynamic entirely. It lets the team pull the highest-risk, highest-obligation, most-remediable assets to the top and work down, demonstrating measurable risk reduction with each cycle instead of chasing a violation count that never reaches zero. It also lets leadership see progress in terms that matter, risk reduced and obligations met, rather than raw asset counts that do not map to exposure. An inventory that evaluates and scores itself is the difference between a cryptographic program that knows what it has and one that knows what to do about it.
FAQ
Q: Why isn’t a complete inventory enough on its own? Because a complete inventory lists assets without judging them, so it cannot answer which assets violate your standards or which to fix first. Every asset sits with equal weight and no verdict. Turning the inventory into action requires evaluating it against policy, mapping it to the standards you are measured by, and scoring findings so they can be ordered. Completeness is a precondition for those steps, not a substitute for them.
Q: Why does the policy engine have to be configurable? Because every organization’s acceptable-cryptography definition differs, reflecting its risk tolerance, regulatory environment, and legacy constraints. A configurable engine lets the organization encode its own rules, including the exceptions it has chosen to accept, and enforce them consistently. A hard-coded rule set either overstates violations against a stricter standard than the organization adopted or understates them against a looser one.
Q: What does standards mapping add beyond the policy engine? It connects the organization’s internal rules to the external baselines it is measured against, such as NIST SP 800-131A, CNSA 2.0, FIPS 140-3, and PCI DSS 4.0, as well as the organization’s own certificate policy and sector baselines. That mapping turns a compliance question into a concrete query: these assets conform, these do not, and here is the specific rule each nonconforming asset breaks. It makes compliance demonstrable rather than merely asserted.
Q: Why does risk scoring need to be multi-factor? Because risk is a property of an asset in context, not of its algorithm in isolation. A single-factor model that scores only algorithm strength over-alarms on weak crypto protecting trivial internal assets and under-alarms on strong crypto in high-stakes trust roles. Weighing exposure, business criticality, trust role, key length, validity period, known vulnerabilities, and remediation effort produces a ranking that matches real risk.
Q: Why include ease of remediation in a risk score? Because two assets of equal intrinsic risk are not equal priorities if one is a configuration change and the other requires a hardware refresh. A score that ignores remediation effort produces a worklist that cannot be executed in order. Including it lets a team pull the highest-risk, most-remediable assets to the top and show measurable risk reduction each cycle.
About QCecuring
QCecuring evaluates every discovered asset through a configurable policy engine covering approved algorithms, key sizes, curves, certificate lifetimes, permitted CAs, trust anchors, and protocols, maps findings to NIST, CNSA 2.0, FIPS 140-3, PCI DSS 4.0, and an organization’s own CP and CPS, and scores risk across algorithm weakness, exposure, criticality, trust role, validity, known vulnerabilities, and remediation effort. The result is an inventory that evaluates itself and hands teams an ordered worklist.
See your inventory evaluated against policy and ranked by real risk
Tags: CBOM, Compliance, Policy Engine, Risk Scoring, NIST SP 800-131A, CNSA 2.0, FIPS 140-3, PCI DSS 4.0, Cryptographic Governance, Certificate Policy, Standards Mapping, Crypto Risk