Telecommunications cryptography rarely belongs to one application or one owner. On September 30, ATIS released a telecom-specific Cryptographic Bill of Materials profile intended to apply the CycloneDX CBOM model to 5G assets and dependencies. The announcement points to network functions, interfaces, protocols, certificates, keys, authentication mechanisms, and software components as parts of the problem.
The profile is an evolving industry artifact, not proof that any operator’s inventory is complete or quantum-safe. Its importance is architectural: a useful telecom CBOM must describe cryptography across supplier and organizational boundaries, not merely list algorithms found in a package.
Interfaces are where ownership becomes ambiguous
A 5G service can span radio, transport, core network functions, orchestration, identity, roaming, cloud infrastructure, and management systems. A cryptographic session may terminate at a virtual network function controlled by one team, use certificates issued by another, run on a supplier library, and carry traffic governed by a partner agreement.
If an inventory records only the endpoint, it misses the relationship. If it records only the software component, it misses the deployed protocol and policy. If it records only the certificate, it may not show which interface or trust domain depends on it.
A canonical record should connect:
- the network function, service, interface, and deployment instance;
- the protocol, algorithm, parameter set, certificate, and trust anchor;
- the software, library, module, firmware, and supplier version;
- the operator, vendor, cloud, roaming, and managed-service owners;
- the observed configuration and negotiated behavior;
- the data sensitivity and required protection lifetime; and
- the migration blocker, exception, accountable party, and target date.
A supplier CBOM is evidence, not the full operating picture
Vendors are essential sources because they can describe embedded libraries, firmware, hardware modules, and code paths that operators cannot inspect directly. But a supplier artifact may represent a product release rather than a customer’s deployed configuration. It may not include operator certificates, local policy, negotiated protocols, external peers, or runtime fallbacks.
Operators should preserve supplier CBOMs with product identity, version, issue date, signature or provenance, and declared scope. They should then reconcile those claims with deployment and observation evidence. Differences are findings: the installed version may be older, a feature may be disabled, or an interface may terminate somewhere unexpected.
The reverse also matters. Operators need a safe way to return discovered gaps without exposing sensitive topology or key material. Exchange contracts should define identifiers, update cadence, correction processes, confidentiality, and responsibility when a dependency changes.
5G migration cannot be reduced to one readiness score
Quantum risk differs by cryptographic purpose. Key establishment protecting long-lived sensitive traffic may deserve early action because of harvest-now, decrypt-later exposure. Authentication, signaling, firmware signing, subscriber identity, management access, and secure boot have different failure modes and upgrade paths.
A CBOM should preserve those purposes rather than flatten them into “PQC ready.” It should also distinguish implemented, enabled, negotiated, and covered states. A network function may contain an ML-KEM implementation without using it on the relevant interface. A lab test may prove interoperability without proving fleet coverage.
Priority should combine data lifetime, exposure, criticality, replacement lead time, upgrade mechanism, supplier readiness, interoperability, and evidence confidence. This makes the inventory useful for sequencing rather than merely reporting.
What organizations should do next
First, define the telecom scope using services and interfaces, then map products and components beneath it. This keeps discovery tied to operational outcomes.
Second, agree on stable identifiers for network functions, product versions, certificates, interfaces, and cryptographic assets before exchanging CBOMs. Reconciliation is unreliable when each party names the same dependency differently.
Third, require provenance and freshness. Record whether each fact came from a vendor declaration, package analysis, configuration, active test, passive observation, or manual review.
Fourth, assign every cross-boundary gap. “Vendor dependency” is not an owner. Record the party responsible for evidence, remediation, validation, and acceptance.
Finally, re-observe after change. A migration ticket is not closure; the deployed interface must be evaluated again and the resulting proof linked to the affected inventory records.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop—discovery, canonical inventory, evaluation, action, and proof—helps teams connect cryptographic assets and relationships to systems, suppliers, owners, policies, remediation, and evidence.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted, not indiscriminate network scanning. Vista is not a vulnerability scanner, and incomplete discovery is not proof of absence.
Learn more about Vista’s CBOM and compliance and cryptographic inventory approach.
Where uncertainty remains
ATIS says the profile will continue to evolve and expand to additional services. Its practical interoperability, adoption, and coverage still need to be demonstrated across operators and vendors. The durable lesson is that telecom migration depends on shared, traceable relationships and explicit ownership—not an isolated component list.