On November 4, NIST opened a pre-draft call for comments on revising SP 800-108, its recommendation for key derivation using pseudorandom functions. The announcement cites research affecting output indistinguishability and key-control security, asks about CMAC-based constructions, and questions whether Double-Pipeline Iteration Mode should remain. Comments are due December 18, 2026.
This is not a new mandate or final revision. It is an early request for evidence. Yet it already delivers an operational lesson: an inventory entry that says only “HMAC,” “CMAC,” or “NIST approved” cannot tell an organization whether a particular construction is affected or what a change would disrupt.
The implementation details are the control
SP 800-108 covers KDFs built from CMAC, HMAC, and KMAC and includes Counter, Feedback, and Double-Pipeline modes for fixed-output pseudorandom functions. NIST’s questions address permitted initialization-vector choices, counters, context derivation, key-control properties, and compatibility consequences.
A useful inventory therefore needs to connect:
- KDF standard, revision, mode, pseudorandom function, underlying primitive, parameters, and output length;
- initialization-vector source, counter behavior, label, context, separator, encoding, and domain-separation rules;
- key-derivation key origin, protection boundary, rotation, access policy, and authorized role;
- implementation, library, module, firmware, provider, version, build, and validation status;
- protocol, application, service, interface, device, host, environment, and physical or cloud location;
- derived-key purpose, consumer, lifetime, exportability, storage, destruction, and downstream dependency;
- supplier, product owner, service owner, risk owner, exception, and remediation work item; and
- discovery source, timestamp, scope, confidence, and known coverage gaps.
Without those relationships, a standards change becomes a keyword search followed by manual archaeology. With them, teams can identify the exact implementations and services that require analysis.
“Uses HMAC” is not enough
The NIST announcement discusses distinguishers against certain Feedback-mode constructions under some allowed IV choices. That does not mean every HMAC use is affected. It means mode and inputs matter. A broad algorithm label can create both false alarms and false reassurance.
Inventory should preserve the full construction, including values that teams may currently treat as mere configuration. If the configuration is assembled dynamically, the record should identify the code path and configuration authority, then link test evidence from representative runtime instances.
The same discipline applies to key-control security. Whether an attacker can influence derived output may depend on who knows the derivation key, who selects inputs, and what the application assumes. Those trust relationships cannot be inferred from an algorithm name.
Compatibility evidence belongs beside exposure
NIST is explicitly asking about implementation, interoperability, validation, and transition effects. Organizations that use these constructions can contribute better feedback if they know where each mode runs, which products expose configuration, which interfaces are fixed, and which dependencies would break after a change.
A transition record should distinguish support, configuration, test, deployment, and verified use. A vendor statement that a newer library supports an alternative is not proof that a production service selected it. Likewise, a passing unit test is not evidence that every data path and failover node has moved.
Retain exact version, configuration, test vector, result, environment, and time. Link each result to the canonical implementation and asset rather than storing screenshots in an isolated project folder.
What organizations should do now
First, locate uses of SP 800-108 and similar KDF constructions in code, appliances, HSM policies, firmware, protocols, and supplier documentation. Record the full construction and application context.
Second, identify where IVs, counters, labels, and context are selected. Determine whether those values are fixed, derived, externally influenced, or controlled by a party that also knows the derivation key.
Third, map consumers of derived keys and test plausible alternatives in representative environments. Include interoperability, rollback, validation, performance, and failure behavior.
Finally, organizations with relevant deployment evidence should consider answering NIST’s questions before December 18. Public standards improve when operational consequences are visible before normative text is settled.
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 implementations and policy to applications, devices, hosts, locations, owners, suppliers, 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
NIST has not yet published a draft revision, and the final treatment of affected constructions may differ from the options in this call. The cited findings do not establish that every implementation is exploitable. Risk depends on construction, inputs, threat model, implementation, and application context. Teams should avoid declaring either exposure or safety from incomplete discovery.
Source
- Pre-Draft Call for Comments: Recommendation for Key Derivation Using Pseudorandom Functions, National Institute of Standards and Technology, November 4, 2026.