The IETF’s latest work on Hybrid Public Key Encryption is a useful reminder that modern cryptography rarely fits in one algorithm field. Updated October 28, draft-ietf-hpke-hpke-06 specifies HPKE as a composition of a key encapsulation mechanism, key derivation function, and authenticated-encryption algorithm. If approved, it would obsolete RFC 9180.
The draft is still a work in progress, not a final RFC. Its operational lesson is already clear: an inventory entry that says “HPKE,” “public-key encryption,” or even the name of one KEM is not enough to evaluate security, interoperability, or migration readiness.
The ciphersuite is the unit that matters
HPKE defines a ciphersuite as the triple of KEM, KDF, and AEAD. Each component contributes different security assumptions, implementation behavior, identifiers, and lifecycle constraints. The selected operating mode adds more context: base, authenticated, pre-shared-key, or authenticated pre-shared-key use do not have identical properties.
A defensible inventory should therefore capture at least:
- the complete KEM, KDF, and AEAD identifiers and parameters;
- the HPKE mode and protocol or application that invokes it;
- library, module, version, build, configuration, and validation status;
- recipient, sender, and pre-shared-key relationships where applicable;
- key origin, storage, rotation, custody, and affected trust boundary;
- application, service, endpoint, device, host, location, environment, owner, and supplier;
- data classification, confidentiality lifetime, exposure, and business criticality;
- negotiation, fallback, error handling, and peer compatibility;
- discovery source, timestamp, scope, confidence, and coverage gap; and
- policy status, target state, exception, work item, and verification evidence.
That model lets a team answer whether two “HPKE” deployments are actually compatible, whether they rely on the same assumptions, and whether one migration plan can cover both.
“Hybrid” does not automatically mean post-quantum
The name Hybrid Public Key Encryption refers to combining asymmetric and symmetric cryptography. It should not be confused with a hybrid classical-plus-post-quantum migration construction.
The draft explains that HPKE can provide post-quantum security when used with a post-quantum-secure KEM. It also describes a property of pre-shared-key mode under certain conditions. Those statements do not make every HPKE deployment quantum resistant. A deployment using a classical Diffie-Hellman KEM remains dependent on that classical assumption.
Inventory systems should avoid deriving quantum readiness from a protocol family name. Readiness must be evaluated from the instantiated KEM, mode, implementation, key handling, peer behavior, and governing policy.
Interfaces and error behavior belong in the risk picture
The draft covers serialization, input validation, sequence limits, API considerations, and errors. Those details matter operationally. Some malformed keys can fail during encapsulation; other KEMs may surface an equivalent problem only when decryption occurs. Applications may expose failures differently, creating security and reliability differences even when nominal algorithm selections match.
This is why cryptographic inventory cannot stop at static component names. Teams need links from a discovered primitive to the code path, API, runtime configuration, and test evidence that demonstrate how it is used. A CBOM can exchange part of that information, while the infrastructure system of record supplies deployment, ownership, and location context.
Protocol updates create inventory work before migration work
Because the draft is intended to replace RFC 9180, organizations using HPKE should identify which applications and dependencies claim RFC 9180 compatibility, which library versions implement it, and which peers rely on specific behavior. That does not mean changing production systems to follow an Internet-Draft. It means knowing the affected population so the eventual standards and supplier decisions can be evaluated quickly.
Useful lifecycle states distinguish observed, supported, configured, negotiated, exercised, tested, and retired. A library containing an HPKE implementation is not proof that an application activates it. Likewise, a configuration file is not proof of what a peer negotiated in production.
What organizations should do next
First, search source, dependencies, configurations, endpoints, and vendor documentation for HPKE and RFC 9180 references. Preserve the discovery method and confidence.
Second, normalize findings into full ciphersuites and modes, then join them to canonical application and infrastructure identifiers. Record peers and supplier dependencies.
Third, assess quantum readiness from the concrete KEM and deployment context rather than the word “hybrid.” Keep unknown or dynamically selected components visible.
Finally, monitor the IETF document through publication and supplier adoption. Treat the current draft as planning input, not a production mandate, and require interoperability and security evidence before closing any change.
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 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 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
Internet-Drafts can change, be replaced, or expire. The final RFC text, implementation timelines, validation status, and product support may differ from today’s revision. Organizations should follow the IETF record and their suppliers rather than hard-code draft behavior into policy prematurely.
Source
- Hybrid Public Key Encryption, draft-ietf-hpke-hpke-06, Internet Engineering Task Force, updated October 28, 2026.