Join our Newsletter — 33% off our NHI Course

What is an example of a Message Integrity Code in practice?

A Message Integrity Code is a value attached to a message to detect tampering or accidental corruption. In practice, systems compare the received code with a freshly computed one before trusting the message. Practitioners use it on API calls, queued messages, and configuration updates to spot alteration in transit and reject forged or modified content.

A practical example of a Message Integrity Code

A common example is an HMAC on an API request. The sender computes a tag over the payload and selected headers, and the receiver recomputes the same tag before accepting the message. If the values do not match, the message is discarded because it may have been altered, truncated, replayed, or forged.

In practice, the MAC value is useful anywhere a system needs to trust message contents more than transport alone can guarantee. That includes service-to-service calls, queue messages, webhook deliveries, and signed configuration updates where even a small change to the body or metadata can affect authorisation or behaviour.

How a Message Integrity Code is used in real systems

A message integrity code is not usually a standalone feature. It is part of a protocol or application design that defines exactly what is covered, which key is used, and what the verifier must compare. The protected data often includes the body plus fields such as timestamp, nonce, endpoint, or sequence number so that the receiver can spot tampering and reject a message that no longer matches the expected context.

In security terms, the value gives the receiver confidence that the message has not been changed since it was created by a party that knows the shared secret. That makes it appropriate for integrity checking, but not for confidentiality. If the content also needs to remain private, the MAC is combined with encryption rather than treated as a substitute for it.

Common implementations include HMAC-SHA-256 in application code, an authenticated message format in a queue, or a signed callback where the sender and receiver both know how the tag is constructed. The exact algorithm matters less than the verification rule: recompute, compare, and fail closed if the result differs.

What a MAC example is protecting against

The main benefit is detecting message alteration before the receiver acts on it. That matters when a forged amount, modified account identifier, changed routing instruction, or edited configuration value could create an operational or security impact. A correct MAC check prevents the system from treating untrusted content as if it came from a trusted sender.

It also helps expose accidental corruption. Network faults, queue duplication, bad serialization, or application bugs can all change bytes in transit, and a MAC gives the receiver a deterministic way to detect that mismatch instead of silently processing bad data.

A MAC does not solve every trust problem. If the shared key is exposed, an attacker can create valid tags. If the verifier checks only part of the message, an attacker may alter an uncovered field without detection. If the receiver accepts stale messages, integrity alone does not stop replay.

Risk and Threat Considerations

message integrity controls fail when teams assume transport security, such as TLS, makes message verification unnecessary. That creates a gap if a message is copied, replayed, queued, or altered by a compromised integration point before it reaches the application.

Failure mechanism: The verifier either does not cover the full security-relevant message or does not recompute and compare the tag before acting, so modified or replayed content is accepted as genuine.

Impact: Attackers or faulty intermediaries can change instructions, inject forged requests, or trigger unsafe automation, which can cascade into fraud, privilege misuse, or bad system state.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
OWASP API Security Top 10 API2 — Broken Authentication API messages rely on trusted sender verification and tamper detection.
Recommendation — Verify API message authenticity before processing state-changing requests.
NIST SP 800-53 Rev 5 IA-7 — Cryptographic Module Authentication MACs provide cryptographic authentication of message origin and integrity.
SC-16 — Transmission Integrity A MAC directly protects message integrity in transit and detects alteration.
Recommendation — Use cryptographic authentication to verify message integrity before acceptance. Protect transmitted data with integrity checks that fail closed on mismatch.
ISO/IEC 27001:2022 A.8.24 — Use of cryptography MACs are a cryptographic control used to preserve message integrity.
Recommendation — Apply cryptography where message integrity must be verified in transit.
CIS Controls v8 CIS-3 — Data Protection MAC verification helps protect data from unauthorized alteration.
Recommendation — Use integrity checks on sensitive messages and automated transactions.

Practitioner Guidance

What to verify: Define exactly which fields are inside the MAC calculation, and confirm the receiver rejects any message when the tag is missing, stale, malformed, or mismatched. A partial verification rule is usually worse than none because it creates false confidence.

Decision rule: If the message can change money movement, access decisions, workflow state, or configuration, treat integrity verification as mandatory and pair it with freshness controls such as timestamps or nonces. If the message is low impact and fully internal, the operational burden may not justify a MAC on every path.

Practitioner takeaway: The practical test is whether the receiver can prove the message is exactly what the sender created, for the exact fields that matter, before any business logic runs.