Post-quantum migration is reaching the object formats used by devices, APIs, tokens, and constrained systems. On October 29, the IETF COSE Working Group published draft-ietf-cose-pqc-kem-00, describing conventions for using post-quantum key encapsulation mechanisms with CBOR Object Signing and Encryption.
This first working-group revision is an Internet-Draft and can change. It should not be treated as a final implementation mandate. It does, however, illustrate why a cryptographic inventory must capture the complete object-protection construction and its deployment context, not only the name of a post-quantum algorithm.
The protected object carries operational meaning
A KEM establishes shared secret material; the surrounding COSE construction determines how recipients, keys, algorithm identifiers, headers, and encrypted content fit together. If an inventory records only “ML-KEM” or “PQC enabled,” it cannot answer whether two implementations interoperate or whether the object is handled according to policy.
For each use, teams should record:
- COSE message type, application profile, protocol, content type, and schema version;
- KEM algorithm, parameter set, identifier, public key, and recipient relationship;
- key derivation, content-encryption algorithm, protected headers, and external authenticated data;
- sender, recipient, device, application, service, host, location, and environment;
- library, module, firmware, build, configuration, and validation status;
- key generation, provisioning, storage, custody, rotation, recovery, and destruction;
- message-size limits, fragmentation, transport, parsing, and resource constraints;
- supplier, dependency, peer support, negotiation, fallback, and downgrade behavior;
- policy status, target state, exception, accountable owner, and verification evidence; and
- discovery source, timestamp, scope, confidence, and coverage gaps.
These fields connect a standards identifier to the real asset and data flow where it matters.
Metadata is part of the security boundary
Cryptographic operations depend on more than secret values. Algorithm identifiers, recipient information, headers, context, and application profiles tell implementations how to process an object and what meaning to assign to the result.
That metadata needs governance. Ambiguous encodings, mismatched identifiers, unprotected fields, permissive parsers, or inconsistent application profiles can undermine otherwise sound algorithms. A CBOM can describe algorithms and components, but the canonical infrastructure inventory must also identify which device, workload, data, and owner use the object format.
Testing should include malformed and unexpected inputs, not only successful exchanges. Inventory records should link to the exact vectors, versions, and results that support a compatibility claim.
Constrained environments make size and processing visible
COSE is common where compact binary representation matters. Post-quantum keys and encapsulated values may be larger than the classical material they replace. That can affect packetization, storage, memory, latency, battery use, gateways, queues, and intermediary limits.
A migration plan should therefore join cryptographic records to device and network capabilities. The same KEM profile may work comfortably in a server application and fail in a sensor, smart card, embedded controller, or low-bandwidth link.
Selected-asset testing is more useful than assuming support from a library feature list. Teams should measure complete messages over the actual transport and preserve resource and failure evidence for each device class.
Algorithm support is not deployment proof
A library may implement a PQ KEM while the application never invokes it, a peer rejects it, or a fallback path silently selects classical behavior. Conversely, static analysis may find an algorithm path that is unreachable in production.
Lifecycle states should distinguish present, configured, provisioned, offered, selected, exercised, verified, and retired. Runtime observation, configuration inspection, dependency analysis, device inventory, and supplier evidence each contribute different facts. Gaps must remain visible rather than being interpreted as proof of absence.
What organizations should do next
First, identify COSE use across firmware, device identity, APIs, tokens, update systems, and embedded protocols. Connect each use to canonical assets, owners, data, and locations.
Second, inventory full constructions: KEM, derivation, content encryption, headers, recipient model, library, profile, and transport. Avoid a single “PQC” field.
Third, build test matrices for message size, parsing, memory, latency, interoperability, downgrade, malformed inputs, and recovery. Preserve exact implementation versions and evidence.
Finally, monitor the COSE Working Group draft and dependent specifications. Keep draft experiments isolated from production requirements until identifiers, semantics, implementations, and policy are sufficiently stable.
How Vista Platform helps
Vista Platform is a self-hosted infrastructure inventory and DCIM platform with cryptographic posture built in. It serves as a cryptographic system of record through discovery, canonical inventory, evaluation, action, and proof. Teams can connect cryptographic findings to applications, devices, hosts, locations, owners, suppliers, policy, exceptions, and migration evidence.
Vista Core is source-available 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 rather than indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Explore Vista’s cryptographic inventory, post-quantum migration, and CBOM and compliance resources.
Where uncertainty remains
This is an initial working-group draft. Algorithm registrations, encoding conventions, security analysis, test vectors, implementation support, and interoperability guidance may change. Even a final specification will not establish that every device, transport, and supplier can support the resulting object sizes and operational model.
Source
- Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for COSE, draft-ietf-cose-pqc-kem-00, Internet Engineering Task Force, October 29, 2026.