NIST SP 800-185: Cryptographic Lifecycle Management Beyond PQC

PQC is not the only reason your cryptographic dependencies need watching.

On 8 October 2026, NIST published an initial public draft of SP 800-185 Revision 1, covering the SHA-3-derived functions cSHAKE, KMAC, TupleHash and ParallelHash.

The proposed revision introduces streaming interfaces for extendable-output function computations. These allow applications to process input and obtain output incrementally without knowing the complete input or total output length in advance. Public comments close on 7 December 2026.

The NIST draft publication page provides the specification and consultation details.

This is not a new PQC standard. It is a proposed revision to specifications for existing cryptographic functions.

That distinction matters. An organisation can have a defined PQC migration programme while still lacking a process for reviewing changes to the cryptography it already uses.

Cryptographic lifecycle management must cover both.

What the NIST SP 800-185 draft changes

The proposed revision centres on streaming interfaces. It also includes an important qualification: the single-call interfaces are equivalent to the functions defined in the previous version.

The proposal therefore concerns how implementations access these functions, rather than announcing replacement algorithms.

That is a different kind of change from introducing a new cryptographic primitive. Its relevance depends on which functions an organisation uses, how they are implemented and whether streaming access would affect current or planned applications.

What is an extendable-output function?

An extendable-output function, or XOF, supports variable-length output rather than only a fixed-size digest.

Under the proposed streaming interfaces, applications can supply input incrementally and obtain output incrementally, instead of requiring complete lengths upfront.

NIST describes three interface operations:

• INIT initialises the computation.

• ABSORB supplies input.

• SQUEEZE obtains output.

The draft includes illustrative pseudocode. However, NIST defines correct streaming behaviour in relation to the corresponding single-call interfaces.

That relationship gives implementers a reference against which to assess their streaming behaviour. Adding an interface does not remove the need to preserve the function’s specified result.

Why TupleHash needs particular attention

The draft identifies a distinction that a headline about “streaming support” could easily miss.

For cSHAKE, KMAC and ParallelHash, absorbing one input segment followed by another has the same effect as absorbing their concatenation.

TupleHash behaves differently. Each ABSORB call processes one complete tuple element.

NIST explicitly invites feedback on whether this different use of ABSORB could cause confusion.

This is a concrete implementation-review question. Similar operation names should not be treated as evidence of identical input semantics.

Which cryptographic functions are covered?

The original SP 800-185 publication specifies four SHA-3-derived function families, each with 128-bit and 256-bit security-strength variants.

They serve different purposes. A governance review should identify the actual function and implementation in use, rather than stopping at a broad label such as “SHA-3”.

cSHAKE: customisable SHAKE

cSHAKE is a customisable variant of SHAKE. Its customisation capabilities allow applications to distinguish particular uses of the function.

KMAC: message authentication and pseudorandom functions

KMAC, the Keccak Message Authentication Code, is a variable-length message authentication code. It can also operate as a pseudorandom function.

TupleHash: preserving input structure

TupleHash hashes tuples of input strings. It is designed to avoid trivial collisions arising from ambiguous treatment of those inputs.

The proposed streaming interface preserves the significance of individual tuple elements. How an implementation divides and submits those elements therefore matters.

ParallelHash: parallel processing of long messages

ParallelHash supports hashing very long messages in parallel.

Like the other functions covered by this revision, it belongs to the SHA-3-derived functions specification. Its inclusion does not turn the draft into a new public-key PQC standard.

Why this matters for cryptographic lifecycle management

The draft does not, by itself, establish that an organisation must replace its existing implementation. NIST’s statement that the single-call interfaces remain equivalent is an important boundary.

The governance opportunity is narrower and more useful: assess whether the proposed interfaces affect applications, libraries, supplier products or planned development.

A practical review should connect three things:

• The relevant standards and their publication status.

• The implementations and products that depend on them.

• The people responsible for assessing and approving change.

Without those connections, standards monitoring becomes a collection of announcements rather than a decision process.

This is the continuing oversight addressed by SITG-Consulting’s cryptographic governance services: connecting cryptographic assets, organisational risk and accountable control.

An inventory is the starting point

An inventory should help answer where the affected functions are used and which implementations provide them.

For this review, useful records would include:

• Function name and relevant mode of operation.

• Library, module or supplier product.

• Version and deployment location.

• Application dependency.

• Technical owner.

• Evidence supporting the identification.

These are proposed review fields, not new requirements imposed by the draft.

Their purpose is to make the next decision possible: whether the revision has any relevance to a specific deployed or planned implementation.

Where organisations lack that visibility, the Quantum-Cryptographic Discovery Sprint provides a structured starting point for identifying cryptographic assets and dependencies across the estate.

Discovery supports subsequent assessment. It does not replace function-specific implementation review.

Ownership turns discovery into a decision

Knowing that a dependency exists is not the same as knowing who will assess it.

A useful ownership model identifies who monitors the standard, who reviews implementation implications, who engages the supplier and who approves any resulting change.

That assessment may conclude that no action is currently required. A documented decision not to change can be a legitimate outcome.

The objective is informed control, not change for its own sake.

The wider distinction between discovering cryptography and controlling it is explored in PQC Is Exposing the Cryptographic Governance and Control Gap.

PQC migration and cryptographic governance are related, but different

The SP 800-185 draft specifies SHA-3-derived functions and their proposed streaming interfaces. It does not introduce a new key-establishment or digital-signature algorithm.

It should not be presented as a new PQC standard.

That does not make it irrelevant to organisations whose attention is concentrated on PQC. It exposes a scope question: who reviews cryptographic changes that sit outside the migration programme?

A migration programme addresses a defined transition. Cryptographic lifecycle management also needs a continuing mechanism for evaluating standards revisions, implementation changes and supplier dependencies outside that transition.

These responsibilities should be connected, but not conflated.

Organisations reviewing their migration strategy and its governance can use the PQC Strategy & Readiness Assessment to examine readiness, third-party exposure and the decisions supporting the programme.

That is a broader readiness review, not a certification of compliance with the SP 800-185 draft.

What organisations should review now

The proportionate response is an impact assessment, not an automatic upgrade.

1. Confirm whether the functions are relevant

Establish whether cSHAKE, KMAC, TupleHash or ParallelHash appear in deployed systems, supplier products or planned development.

Using SHA-3 does not automatically establish that an organisation uses the specific functions covered by SP 800-185.

Record what is known, what remains uncertain and where supplier evidence is needed.

2. Review implementation plans

Ask maintainers or suppliers whether they intend to support the proposed streaming interfaces and what that would mean for application integration and testing.

Keep proposed behaviour separate from functionality already available in a product.

A draft specification, an implementation roadmap and a deployed capability are different things.

3. Examine interface semantics

Where streaming support is relevant, review how input segmentation and output requests are handled.

TupleHash deserves explicit attention because its ABSORB operation processes complete tuple elements, unlike the concatenation behaviour described for cSHAKE, KMAC and ParallelHash.

The assessment should examine the actual implementation, not infer correctness from familiar interface names.

4. Record the assessment and next review point

Document applicability, ownership, supplier response and the next review point.

The outcome might be to monitor the final publication, investigate a development requirement or submit technical feedback.

It should follow the evidence available for the implementation concerned.

What this draft does not establish

The announcement should not be presented as evidence that:

• Existing implementations are broken.

• A newly disclosed vulnerability requires urgent remediation.

• A final revised standard has already been issued.

• A new PQC migration deadline has been introduced.

NIST identifies the publication as an initial public draft and states that the single-call interfaces are equivalent to those in the previous version.

Those facts support a measured review, not an unsupported replacement narrative.

The revision also follows an established review process. NIST’s March 2025 decision to revise SP 800-185 had already identified streaming specifications as a planned development.

Public consultation: a specific opportunity to contribute

The public comment period closes on 7 December 2026.

Developers, library maintainers and users can consult the NIST draft publication page for the specification and submission information.

The consultation provides an opportunity to examine whether the proposed interfaces are clear and implementable. NIST’s question about TupleHash’s ABSORB behaviour gives reviewers a specific issue to assess.

For enterprise governance teams, the immediate question is simpler:

Your PQC programme may have an owner. Does the rest of your cryptographic lifecycle?

Review your cryptographic visibility and accountability

If your organisation cannot identify the relevant implementations, dependencies and owners, start with the Quantum-Cryptographic Discovery Sprint.

If you already have a migration strategy but need independent scrutiny of its assumptions, supplier exposure and governance, review the PQC Strategy & Readiness Assessment.