Associated data is authenticated without being hidden
The RFC 5116 interface takes a key, nonce, plaintext and associated data, returning ciphertext or failure. Plaintext is confidential and authenticated; associated data is authenticated but left unencrypted, allowing public versions, sequence numbers or routing context to be bound.
A readable header may still need tamper detection. Including its encoded bytes as associated data binds them to verification, but the protocol must define which fields and encoding are covered. The algorithm cannot infer every important context.
References: [1]
Failed verification is not usable plaintext
Authenticated decryption yields verified plaintext or failure, not a partially unverified message to act on as trusted data. Computing some decrypted bytes differs from accepting integrity; business actions should not depend on those bytes before verification.
This is not a publicly verifiable digital signature or an automatic access-control decision. Shared-key message validity still needs to be connected to identities and permissions by the protocol, and the AEAD interface itself does not provide anti-replay service.
References: [1]
Nonce obligations depend on the construction and protocol
For algorithms requiring unique nonces under a key, reuse for encryption can break security; AES-GCM is an important example. Processes, restarts and devices sharing keys must coordinate uniqueness rather than treating the nonce as another secret key.
Additional misuse resistance is not inherent in every AEAD. RFC 9771 distinguishes such properties, and tolerance of certain errors does not permit unlimited reuse, ignored usage limits or absent replay state. The selected construction and protocol determine the guarantee.