Define cryptographic policies
Turn your organization’s cryptographic standards into policies in DigiCert® Quantum Central to automatically identify assets requiring attention.
Define policies to govern your current cryptographic environment, including algorithm strength, key sizes, certificate status, TLS configurations, key usage, cryptographic sources, and quantum readiness.
When an asset matches the criteria of an active policy, Quantum Central flags it as a policy violation. Policies provide visibility into cryptographic risks but do not block or change your assets.
The severity assigned to a policy is inherited by the violations it creates.
What you can govern
Each policy applies to one type of asset. The available criteria depend on the selected asset type.
Asset type | Examples of what you can evaluate |
|---|---|
Certificate | Key and signature algorithms, key size, certificate status, issuer, and quantum safety |
Key | Algorithm, key size, key usage, source, and quantum safety |
Endpoint | Supported protocols, cipher suites, port, and host name |
Applications | Environment, owner, criticality, and other application attributes |
This lets you use policies for different parts of an enterprise cryptographic program. For example, you can:
Detect cryptographically weak or deprecated algorithms.
Enforce minimum key-strength requirements.
Identify expired or revoked certificates.
Find endpoints that support deprecated protocols or cipher suites.
Identify keys created in unapproved sources or used for particular purposes.
Measure and prioritize gaps in quantum readiness.
Apply different governance expectations to production and non-production applications.
Default policy
Quantum Central includes the Certificates with Weak Keys policy for every account. This policy is active by default and flags certificates that use RSA keys smaller than 2048 bits.
The default policy establishes a minimum classical-security baseline. Create additional policies to reflect your organization’s standards, regulatory requirements, migration plans, and accepted cryptographic practices.
Design an effective policy
Before creating a policy, define the standard you want to apply and translate it into the conditions that Quantum Central should flag.
Describe the violating condition
Policy criteria describe the condition that represents a violation, not the desired state.
For example, a standard might say RSA certificate keys must be at least 2048 bits.
In the policy builder, express the condition that violates that standard:
Key algorithm equals RSA AND Key size is less than 2048
A certificate is flagged only when both conditions are true.
The same approach applies to other types of standards:
Standard | Criteria that identify a violation |
|---|---|
Endpoints must support TLS 1.3 | Protocols does not contain TLS 1.3 |
Certificates must not use RSA-SHA1 signatures | Signature algorithm equals RSA-SHA1 |
Certificates must be quantum-safe | Quantum safe equals false |
Keys must use an approved algorithm | Key algorithm not in the approved algorithm list |
Thinking in terms of the violating condition helps prevent rules that flag the opposite of what you intended.
Choose an appropriate severity
Every violation created by a policy inherits the policy’s severity. Choose the severity based on the risk represented by the condition and the expected urgency of remediation.
Severity | Used for |
|---|---|
Critical | Conditions that present an immediate or unacceptable cryptographic risk and require urgent action. Examples include classically breakable keys or an actively prohibited algorithm. |
High | Violations of mandatory security standards that require prioritized remediation, such as insufficient key strength or deprecated TLS configurations. |
Medium | Conditions that require planned remediation but do not represent an immediate exposure, such as gaps in a longer-term quantum-readiness program. |
Low | Cryptographic hygiene or best-practice deviations that should be corrected through routine maintenance. |
Apply severity consistently across policies. Avoid using Critical simply to make a policy more visible; doing so makes it harder for teams to identify the issues that genuinely require immediate attention.
A policy has one severity for every asset it flags. If similar conditions require different severities, ownership, or remediation timelines, consider creating separate policies with narrower criteria.
Combine conditions
A policy can contain multiple parameters and criteria groups:
Parameters within one Group combine with AND. An asset must match every parameter in that Group.
Separate groups combine with OR. An asset is flagged if it matches any group.
For example, a policy could identify certificates with either weak RSA keys or a deprecated signature algorithm:
Group 1 Key algorithm equals RSA AND Key size is less than 2048 OR Group 2 Signature algorithm equals RSA-SHA1
A certificate matching either group is flagged.
Use additional groups when they represent alternative ways of violating the same standard. Create separate policies when the conditions represent different risks, severity, owners, or remediation actions. Focused policies make the resulting violations easier to understand and manage.
Understand the operators
The available operators depend on the selected parameter. Use them to express the violating condition precisely:
Use Equals or In to identify prohibited values.
Use Not equals or Not in to identify values outside an approved set.
Use Less than to identify values below a required minimum.
Use Greater than to identify values above an allowed maximum.
Use Contains or Does not contain for parameters that can contain multiple values, such as protocols or cipher suites.
The policy builder limits the available parameters, operators, and values to combinations supported by the selected asset type.
Consider the scope before activation
Activating a policy evaluates all existing inventory assets of the selected type. A broadly defined condition can therefore create many violations at once.
Before activation:
Review the relevant asset population in Inventory.
Check that the criteria describe the violating condition.
Look for overlap with existing policies.
Confirm that the severity and expected remediation action are appropriate for every matching asset.
Save complex policies as drafts while you review their logic.
An asset can match more than one active policy and produce a separate violation for each policy.
Create a policy
To create a Policy:
From the Quantum Central menu, select Policies, and then select New Policy.
Name the policy and describe the standard or risk it represents.
A useful description explains what the policy detects and why the condition matters. This helps asset owners understand the resulting violations.
Select the asset type and severity determined during policy design.
Under Policy Criteria, define the conditions that identify a violation.
Select Add parameter to add an AND condition to the current group.
Select Add group to add an OR condition to define an alternative violating condition.
Review the complete criteria and choose how to save the policy:
Select Save as draft to preserve the policy without evaluating assets.
Select Create policy to activate the policy and evaluate applicable assets.
A policy must have a unique name and at least one complete condition.
Review your policies
From the Quantum Central menu, select Policies. The page is organized as follows:
At the top, summary cards show the number of Active, Draft, and Archived policies. Inactive policies do not have a separate summary card.
Below the summary cards, use the Active and Archived tabs to switch between current and retired policies. The Active tab includes active, inactive, and draft policies.
In the lower part of the page, the policy list shows each policy’s asset type, severity, status, and last-updated time. Use search and filtering to find specific policies.
View a policy to review its definition and criteria. Use its action menu to edit, duplicate, activate, deactivate, archive, or restore it.
Understand the policy lifecycle
Use policy states to control when a rule evaluates assets without losing its definition or audit history.
State | Effect |
|---|---|
Draft | The policy remains editable and does not evaluate assets or create violations. |
Active | The policy evaluates applicable assets and creates violations for matches. |
Inactive | The policy stops evaluating assets. Existing violations remain available. |
Archived | The policy is retired and read-only. Its violations are removed, but the policy remains available for audit. |
Policies cannot be deleted.
Duplicating a policy creates a draft named Copy of <policy name>. Use duplication as a starting point when you need a similar policy with different scope, severity, or criteria.
Restoring an archived policy returns it as inactive. Previously removed violations are not restored. Activate the policy to evaluate applicable assets again.
When policy changes take effect
Quantum Central evaluates assets against active policies when:
An asset is added to the inventory.
The status or attributes of an asset change.
A policy is created as active.
An inactive policy is activated.
An active policy is edited.
Creating, activating, or editing an active policy evaluates all inventory assets of the selected type. Draft and inactive policies do not evaluate assets.
Because a policy change can evaluate many assets, large evaluations run as Jobs. Review the corresponding job to confirm whether violations were created or closed.