NIST’s GCM Review Closes Today: The Encryption Default Your Engineering Team Still Needs to Understand
Today, 31 July 2026, is the published closing date for public comment on NIST's revision of SP 800-38D, its recommendation for Galois/Counter Mode (GCM) and GMAC. That is standards-policy news, but it should also prompt a practical engineering question: where exactly does your organisation rely on AES-GCM, and can you demonstrate that every implementation uses it safely?
The review does not mean that an organisation should invent a new cipher suite today, nor does it announce a final replacement for GCM. It is a useful deadline to inspect a cryptographic default that appears in application code, cloud SDKs, mobile clients, service-to-service protocols, encrypted archives and security appliances. GCM can provide efficient authenticated encryption. It is not forgiving of poor nonce or key-lifecycle engineering.
The failure mode is usually operational, not mathematical
AES-GCM encrypts data and produces an authentication tag. The construction depends on disciplined use of a nonce (also called an IV) with a key. Reusing a nonce with the same key can seriously undermine confidentiality and authentication. Treating tags as optional, accepting an authentication error and continuing, or allowing concurrent systems to allocate nonces without coordination turns a sound primitive into a fragile deployment.
“We use a secure library” is therefore not the whole answer. A library can be correct while the surrounding application repeats a counter after a restart, derives nonces from a low-entropy timestamp, decrypts before it verifies, or holds one key for far more messages than its own design assumptions permit.
Five questions worth asking your engineering team
- Where is GCM or GMAC used? Build an inventory that includes library, protocol, key owner, nonce source, tag length and data classification. Include vendor components and client applications.
- How is nonce uniqueness enforced per key? Document it, then test it under restart, backup restore, autoscaling, multi-region operation and concurrent writers. Random generation is not evidence of a system-wide uniqueness guarantee.
- Do all authentication failures fail closed? A bad or truncated tag must produce no plaintext that reaches application logic, logs, caches or downstream services.
- What binds context to the ciphertext? Use authenticated associated data where the protocol needs to bind tenant, record type, version, sender or sequence information. Otherwise correctly encrypted data can still be used in the wrong context.
- What limits a key's lifetime? Establish message, byte and time limits appropriate to the implementation; rotate keys before operational counters, retention or replication make the safety assumptions difficult to prove.
Turn a standards review into an engineering control
A productive response is a small, owned work item rather than a vague crypto audit. Select the systems that encrypt the most sensitive data first, capture their current parameters, and add negative tests that deliberately replay a nonce, tamper with a tag, swap associated data and simulate allocator rollback. Record the expected failure behaviour. If a team cannot answer where a nonce comes from, it has found work that should not wait for a future compliance deadline.
Centralising key and nonce allocation is often safer than having every microservice improvise. Where that is not feasible, namespace allocation by key and writer, persist state durably, and make collision detection observable. For envelope encryption, review both layers: the data-encryption key's nonce discipline and the controls governing the key-encryption key.
What this means for policy and procurement
Standards work only helps if it reaches the software that uses the standard. Security architecture reviews, secure-development requirements and supplier questionnaires can ask for explicit answers on authenticated-encryption mode, nonce management, authentication-failure handling, key rotation and upgrade plans. The goal is not to demand a particular implementation from every supplier; it is to prevent an unverified cryptographic assumption from becoming invisible infrastructure.
Keep following NIST's publication process for the revised document. In the meantime, organisations do not need to wait for a final text to improve inventory, safe defaults, test coverage and operational evidence around the GCM deployments they already have.