A configuration management database (CMDB) connects cryptographic findings to identifiable systems, business services, accountable owners and controlled change. A well-maintained CMDB gives post-quantum cryptography (PQC) programs the operational context needed to scope discovery, prioritize migration and verify remediation.
A discovery scan identifies quantum-vulnerable key establishment on a production endpoint. The security team has evidence of exposure, but not yet a migration task. Turning one into the other depends on knowing which system the endpoint belongs to, who is accountable for it, what depends on it and when it can change safely. Those are configuration management and change control questions, and most enterprises already answer them for every other kind of infrastructure change.
Discovery can begin without a CMDB, and it should not wait for a perfect one. At enterprise scale, migration depends on trusted links between findings, systems, accountable owners, business services and controlled change. For organizations that already run those processes in ServiceNow, the CMDB is the natural place to build them.
U.S. federal policy illustrates why system context matters. Executive Order 14412 directs PQC key establishment by December 31, 2030 and digital signatures by December 31, 2031 for covered high value assets and high impact systems, excluding National Security Systems.[1] OMB’s implementing memorandum, M-26-15, connects risk-based migration to existing governance, including comprehensive asset management.[2]
Those deadlines apply to the covered federal systems. The broader operational lesson is that a finding without a trusted system or accountable-owner link is harder to prioritize, assign and track.
The CMDB defines expected scope, and discovery tests it
A CMDB records configuration items (CIs), such as infrastructure, applications and services, together with the relationships between them. It represents what the organization believes should exist, whether each item is operational and which business services it supports. That makes it a better starting point for discovery than an address range: a team can begin with a critical payment service, identify its registered supporting systems and agree which environments and interfaces the assessment must cover.
Because the CMDB describes what the organization expects, discovery cannot rely on it alone. Network observation, cloud provider APIs, certificate and key management systems, code analysis and vendor evidence reveal cryptography the CMDB does not know about. Scoping only from registered CIs reproduces the registry’s blind spots inside the cryptographic inventory.
The useful relationship runs both ways: CMDB records define expected scope and discovery supplies observed evidence. Assets present in both can be enriched and prioritized. A registered CI without cryptographic evidence needs a coverage review. Distinguish an unassessed system, incomplete discovery, a stale record and an assessed system with no applicable cryptography found. Absence of evidence alone establishes neither zero risk nor a confirmed exposure.
A discovered asset with no CI match needs investigation and an accountable record. Assets unknown to both sources remain outside this comparison; independent discovery sources help reveal those blind spots. Coverage statements should always name the methods and scope assessed.
Not every finding maps cleanly to a CI. Cryptography in source code, third-party libraries, SaaS services, firmware or archived data may need a different anchor, such as a business application, a vendor relationship or a data owner, but each finding still needs a record that someone is accountable for.
Resolve asset identity before enriching the finding
Enrichment is only as reliable as the match beneath it, and the obvious keys are unreliable. An IP address is an observation attribute rather than an identity key, and it can be reassigned. A hostname can resolve to a load balancer in front of many applications. One certificate can be deployed across several systems. A CI name helps a human reader but is not a unique identifier.
ServiceNow’s Identification and Reconciliation Engine (IRE) addresses this directly. It applies identification rules to establish each CI’s identity, accepts source-native keys from integrated systems, identifies dependent CIs such as applications in the context of their host and allows only authoritative sources to update CI attributes.[4] A cryptographic integration should work within that model: use stable identifiers and deployment context, record the basis for each match and route ambiguous matches to review. Incorrectly matching a finding to a critical service can be as disruptive as failing to match it at all.
The same discipline applies to data written into the CMDB. Service Graph Connectors import third-party data, standardize it for the CMDB, reconcile it using reconciliation rules and map it to the locations the Common Service Data Model (CSDM) specifies.[5] Which source is authoritative for each attribute should be settled before any data flows. A scanner can be authoritative for an observed protocol or algorithm, but it should not overwrite a business criticality rating that a service owner approved.
Enrichment changes the remediation decision
An algorithm name describes a technical property. It does not establish the business consequence of that property, the team authorized to change it or the order in which dependencies must move. CSDM is ServiceNow’s standardized framework for service-related terms and relationships,[6] and a business service record in ServiceNow carries fields for its owner, support group, business criticality and operational status.[7] The value comes from joining cryptographic evidence to that maintained context.
| Context to connect | Decision it supports | Typical source |
|---|---|---|
| Stable CI identity | Track the same system from discovery through change and verification. | CMDB identification and reconciliation |
| Accountable owner and support group | Establish who accepts the risk and who performs the work. | CMDB service records |
| Business criticality | Weigh business impact and the care a change requires. | CMDB, confirmed by the service owner |
| Application and service relationships | Identify dependent teams, shared infrastructure and changes to coordinate. | CMDB relationships, service maps |
| Environment and lifecycle status | Separate production from test, and retirement candidates from migration candidates. | CMDB |
| External exposure | Distinguish internet-facing endpoints from internal ones when setting priority. | Discovery evidence and network context |
| Data sensitivity and required protection lifetime | Judge exposure to data collected now and decrypted later, and set migration urgency. | Data governance, data owners |
Ownership also needs precision. The service owner, the certificate administrator and the team operating a load balancer are often different people. A remediation record should name both the accountable decision-maker, usually the service owner, and the team able to execute the change, which may be the certificate, platform or network team. This is why cryptographic posture management extends beyond an inventory: the same technical exposure can warrant different remediation priorities depending on data lifetime, business impact, external exposure and the migration path available.
Plan migration around services and their dependencies
Consider a hypothetical payment platform. Discovery observes a TLS endpoint using quantum-vulnerable key establishment. The CMDB match connects the endpoint to a shared load balancer and a payment application service, with an infrastructure support group and an accountable service owner. Investigation then establishes which applications share the termination point, which client populations must remain compatible and which downstream connections need separate assessment. A protocol observation at the front door does not establish the cryptographic state of the connections behind it.
The resulting work is more specific than “replace vulnerable cryptography.” It includes confirming vendor support, identifying the configuration and software changes, testing affected clients, scheduling a change window and agreeing rollback conditions. This is the work that makes post-quantum migration more than an algorithm swap.
A single TLS termination point may offer a bounded place to start. Signature migration can introduce a different set of dependencies: certificate chains, trust anchors, signing systems and the clients that validate their output. Neither transition is complete until the affected participants work together under the intended policy.
CMDB relationships expose operational dependencies, while cryptographic evidence establishes the algorithm, protocol and trust dependencies within that scope. A service map is valuable context, but it is not proof of cryptographic compatibility. NIST’s National Cybersecurity Center of Excellence (NCCoE) migration project reflects a similar distinction by running cryptographic discovery and interoperability testing as separate workstreams:[3] an inventory supports planning, while testing establishes whether the intended transition works. A practical unit of migration is often a service and its dependencies, and managing a queue of individual certificates, keys or algorithm findings fragments one coordinated change across many teams and tickets.
Carry the evidence into remediation and back again
Enrichment earns its value when it changes how work is assigned and completed. A remediation record should carry the affected CI and service, the observed condition, the supporting evidence, an accountable owner, an execution group and a clear acceptance test.
ServiceNow’s IT Remediation Workspace, part of Vulnerability Response, illustrates one operational pattern: remediation owners can create a change request from a remediation task or add the task to an existing change, with an option to add the CIs from its active vulnerable items.[8] Each organization still has to choose the applicable record types, applications and integrations. Importing data through a Service Graph Connector does not by itself orchestrate remediation.
The action will not always be a direct technical fix. It may be a supported software upgrade, a vendor dependency, retirement of an obsolete service or a time-bound exception with an accountable owner. After a change, repeat the discovery or validation appropriate to the affected cryptographic function and the agreed acceptance criteria.
For TLS key-establishment changes, confirm what the deployment actually negotiates, using observed handshakes from representative clients where possible. A server that offers a hybrid key exchange has not migrated a connection until its client uses it. For signature changes, validate the relevant signing, verification and trust paths with the intended participants.
A closed ticket records a workflow outcome. Evidence from the changed environment establishes the technical outcome. Linking both to the same CI and service gives security and operations a shared basis for reporting progress.
Make data quality part of cryptographic posture
CMDB enrichment is only as dependable as its inputs. A current scan linked to a departed owner or an incorrect service relationship produces a confidently wrong remediation decision. A well-maintained CMDB, for this purpose, does not need to be perfect. For a first service it means the CIs in scope are identified, each has a confirmed owner and support group, criticality is current and relationships reflect how the service actually runs.
ServiceNow’s CMDB Health metrics already measure completeness, correctness and compliance, with correctness covering stale, duplicate and orphaned CIs.[9] A cryptographic program should extend that discipline to the links between its own evidence and enterprise records, and measure whether the information is usable for action:
- Coverage: the in-scope CIs with recent cryptographic evidence, and those still unassessed.
- Identity: discoveries with a reliable CI match, and those unmatched or ambiguous.
- Accountability: priority findings with a confirmed owner and execution group.
- Execution: planned changes blocked by vendors, dependencies or missing context.
- Verification: completed changes with fresh evidence showing the intended result.
Each measure needs an explicit denominator and a freshness threshold. A coverage percentage calculated only over assets a scanner already found says little about the systems it missed, and unknown criticality should stay unknown, with work assigned to resolve it, rather than defaulting to low. Discovery coverage and CMDB quality improve together, one important service at a time.
Crypto agility requires an organization that can execute change
NIST defines crypto agility as “the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations.”[10] Achieving that requires suitable technology and an organization able to identify, approve, coordinate and verify changes across many systems. A well-maintained CMDB lets the cryptographic program inherit the enterprise’s existing investment in service ownership, configuration management and change control. Discovery, in turn, gives those processes cryptographic evidence they have usually lacked.
How Qinsight approaches this
Qinsight Atlas focuses on cryptographic discovery, inventory and posture management across supported environments. We treat CMDB information as context for cryptographic evidence. Connecting discovered objects to maintained enterprise records helps teams investigate ownership, criticality and service dependencies.
This approach is part of the enterprise cryptographic posture management lifecycle: collect evidence, normalize it, enrich it with context, assess it and support accountable action. For ServiceNow customers, the practical goal is a traceable path from a finding to the team and service affected, through controlled change and back to fresh evidence.
The scope of CI mapping, data exchange and workflow handoffs should be confirmed for the supported integrations enabled in each deployment. A scoped evaluation should establish what is available, what context is missing and which steps remain with the customer’s existing tools and teams.
Next step: choose one critical service. Establish its expected assets and discover its cryptography, resolve identity, ownership and dependencies, then take one finding through to verified remediation. One complete pass shows whether the organization has an executable migration process and where it needs work. Scope that first cycle with Qinsight.
Sources
1. The White House, Executive Order 14412: Securing the Nation Against Advanced Cryptographic Attacks Signed June 22, 2026. Sets the 2030 and 2031 PQC deadlines for high value assets and high impact systems.
2. Office of Management and Budget, M-26-15: Execution of the Migration to Post-Quantum Cryptography Issued June 24, 2026. Risk-based prioritization and alignment with existing governance and asset management.
3. NIST NCCoE, Migration to Post-Quantum Cryptography Project overview, including the discovery and interoperability testing workstreams.
4. ServiceNow, Identification and Reconciliation Engine (IRE) Identification rules, source-native keys, dependent CIs and authoritative data sources.
5. ServiceNow, Getting started with Service Graph Connectors How third-party data is imported, standardized, reconciled and mapped to CSDM.
6. ServiceNow, What is CSDM (Common Service Data Model)? Definition of the Common Service Data Model.
7. ServiceNow, Create Business Service form Business service fields, including owner, support group, business criticality and operational status (Operational Resilience Workspace).
8. ServiceNow, Create a change request in the IT Remediation Workspace Change requests created from remediation tasks in Vulnerability Response.
9. ServiceNow, CMDB Health KPIs and metrics Completeness, correctness and compliance metrics for the CMDB.
10. NIST CSWP 39 (updated June 2026), Considerations for Achieving Crypto Agility: Strategies and Practices Definition of crypto agility quoted in this article.
Related Qinsight reading
The enterprise cryptographic posture management lifecycle
Post-quantum migration: a practical five-stage framework
CBOM and cryptographic inventory: the two essential layers of cryptographic visibility
Build the evidence behind the argument.
Start with one accredited boundary or one delivered system and produce evidence a reviewer will accept.
