Skip to main content
DataRidge
Category: Cryptography and Encryption

Message Authentication Code

Also known as: MAC, authentication tag, tag, cryptographic checksum
Simply put

A Message Authentication Code (MAC) is a short piece of cryptographic information, sometimes called a tag, attached to a message to confirm that the message has not been altered and that it comes from a party holding the shared secret key. It helps detect both accidental changes and deliberate tampering. It is a security control concerned with integrity and authenticity, and is distinct from data governance concerns such as ownership or lineage.

Formal definition

A Message Authentication Code (MAC) is a cryptographic checksum computed over a message using a symmetric (shared secret) key, used to detect both accidental and intentional modifications of the data and to provide assurance of message origin authenticity. Because verification relies on possession of the same symmetric key by both the sender and verifier, a MAC generally does not provide non-repudiation in the way a digital signature (which uses asymmetric keys) does. This entry addresses the concept and purpose of a MAC only; it does not cover specific MAC constructions or algorithms, key management practices, or how a MAC would be evaluated as a technical or organizational measure under any particular data protection regime. Note that applying a MAC assures integrity and authenticity but does not conceal or transform the underlying data, so it does not by itself render personal data non-personal.

Why it matters

Integrity and authenticity are foundational to trustworthy data handling, and a Message Authentication Code is one of the mechanisms that lets a receiving party detect whether a message has been altered in transit or storage and whether it originated from a party holding the shared secret key. Without such assurance, an organization generally cannot distinguish legitimate data from data that has been accidentally corrupted or deliberately tampered with, which undermines the reliability of any downstream processing or decision-making that depends on that data.

For security and privacy professionals, a MAC is relevant as a technical control that supports the integrity dimension of information security, complementing rather than replacing confidentiality controls. It is important to understand its scope precisely: a MAC assures integrity and authenticity, but because verification depends on both parties holding the same symmetric key, it generally does not provide non-repudiation in the way a digital signature using asymmetric keys does. Anyone relying on a MAC to prove that a specific individual sent a message should recognize this limitation.

A common expert-level error is to treat integrity or authenticity controls as if they transform or conceal data. Applying a MAC does not encrypt, tokenize, or otherwise obscure the underlying message; the data remains readable and, where it consists of personal data, remains personal data. Practitioners should not describe a MAC as making data non-personal or as satisfying any particular data protection obligation on its own. Whether a MAC contributes to appropriate technical and organizational measures under any given regime depends on context and implementation, which this entry does not assess.

Who it's relevant to

Privacy Engineers and Security Architects
Those designing systems that must detect tampering or corruption of data in transit or storage may use a MAC as an integrity and authenticity control. They should scope its role accurately, recognizing that a MAC does not conceal or transform the underlying data and, where that data is personal data, does not render it non-personal.
Information Security Professionals
A MAC sits within the integrity dimension of information security and complements, rather than substitutes for, confidentiality controls. Practitioners should distinguish the assurance a MAC provides, detection of accidental and intentional modification, plus origin authenticity tied to a shared key, from the non-repudiation properties associated with digital signatures.
Data Protection Officers and Compliance Leads
Where a MAC is presented as part of technical measures, DPOs and compliance leads should treat it as a control concerned with integrity and authenticity, distinct from data governance concerns such as ownership or lineage. Whether it contributes to appropriate measures under a specific regime depends on context and implementation and is outside the scope of this entry.

Inside MAC

Shared Secret Key
A MAC relies on a symmetric key known to both the sender and the verifier. Both parties must possess the same key to generate and validate the code, which distinguishes a MAC from a digital signature that uses asymmetric key pairs.
Message Input
The data over which the authentication code is computed. Any change to the message content will, in general, produce a different MAC value when recomputed, which is what enables integrity checking.
Tag or Authentication Code
The fixed-length output produced by the MAC algorithm over the message and key. This tag is transmitted or stored alongside the message and is recomputed by the verifier for comparison.
Verification Process
The recipient recomputes the MAC using the shared key and the received message, then compares it against the transmitted tag. A match generally indicates that the message was not altered and originated from a party holding the key.
Integrity and Authenticity Assurance
A MAC is intended to provide assurance of message integrity and origin authentication among parties sharing the key. It is a security control rather than a data governance mechanism.

Common questions

Answers to the questions practitioners most commonly ask about MAC.

Does a Message Authentication Code (MAC) provide confidentiality or hide the contents of a message?
No. A MAC is designed to provide integrity and authenticity assurance, allowing a recipient who shares the secret key to verify that a message has not been altered and originated from a party holding that key. It does not encrypt or conceal the message content. If confidentiality is required, encryption must be applied separately or in combination with the MAC. Treating a MAC as a substitute for encryption is a common error; the two address different security properties.
Is a MAC the same as a digital signature, and can it prove who sent a message to a third party?
No. A MAC relies on a symmetric secret key shared between the parties, meaning any party holding the key can both generate and verify a valid MAC. Because more than one party can produce a valid tag, a MAC generally does not provide non-repudiation and typically cannot prove authorship to an independent third party. A digital signature, by contrast, uses asymmetric keys and can support non-repudiation. Conflating the two overstates what a MAC establishes.
How should the secret key used for a MAC be managed?
The security of a MAC depends entirely on keeping the shared secret key confidential and available only to the authorized parties. Practices generally include restricting access to the key, rotating keys according to a defined policy, separating keys used for authentication from those used for other purposes, and protecting keys in transit and at rest. Key management sits within information security controls rather than data governance, though governance frameworks may require documented policies and demonstrable evidence of those controls. This entry does not prescribe specific key lengths or rotation intervals.
When should a MAC be used versus an alternative integrity mechanism?
A MAC is generally appropriate where both parties share a secret key and require assurance that a message is unaltered and originates from a key holder. Where non-repudiation or verification by an independent third party is needed, a digital signature is typically more suitable. Where only accidental corruption must be detected and no adversary is assumed, a non-keyed checksum may suffice, though it does not defend against deliberate tampering. Selection depends on the threat model and the parties involved.
Does applying a MAC affect whether data is treated as personal data?
Applying a MAC does not change the classification of the underlying data. A MAC concerns the integrity and authenticity of a message, not the identifiability of individuals within it. If a message contains personal data, it generally remains personal data whether or not a MAC is attached. Integrity mechanisms are distinct from anonymization or pseudonymization and should not be described as making data non-personal. This entry does not address applicable data protection obligations for that content.
How does verifying a MAC fit into a message processing workflow?
In typical implementations, the sender computes a MAC over the message using the shared key and transmits the tag alongside the message. The recipient independently recomputes the MAC over the received message with the same key and compares it to the received tag; a mismatch indicates alteration or an incorrect key. Common practice is to reject any message that fails verification before further processing. This entry does not cover specific algorithm choices, ordering relative to encryption, or protocol-level implementation details.

Common misconceptions

A MAC provides non-repudiation the way a digital signature does.
Because a MAC uses a shared symmetric key, either party holding the key could have produced a valid tag. It generally cannot prove to a third party which specific party created the message, so it typically does not provide non-repudiation. Digital signatures, which use asymmetric keys, are the mechanism generally associated with non-repudiation.
Applying a MAC encrypts the message or renders the underlying data non-personal.
A MAC addresses integrity and authenticity, not confidentiality; it does not conceal the message content. Applying a MAC to data that constitutes personal data does not make that data non-personal, and it does not by itself remove data from the scope of applicable data protection obligations.
A MAC is a data governance control.
A MAC is an information security control focused on confidentiality-adjacent properties of integrity and authenticity. It does not by itself address governance concerns such as data ownership, stewardship, lineage, cataloging, or retention, though it may support policies that governance frameworks reference.

Best practices

Use a MAC to protect message integrity and authenticity among parties that share a key, and pair it with a separate encryption mechanism when confidentiality is also required, since a MAC alone does not conceal content.
Do not rely on a MAC where non-repudiation is a requirement; consider a digital signature approach when you need to demonstrate origin to a third party.
Protect the shared secret key throughout its lifecycle, including generation, distribution, storage, and rotation, because the security assurance of a MAC generally depends on the secrecy and integrity of that key.
Where a MAC is applied to personal data, continue to treat that data as in scope for applicable data protection obligations and do not assume the MAC alters its regulatory status.
Maintain demonstrable evidence of key management and integrity-control decisions so that accountability requirements under relevant governance frameworks can be supported, not merely stated.
Verify tags using a comparison method appropriate to your implementation and validate both the message and its accompanying code before treating the message as authentic.