HMAC vs. Digital Signatures: Understanding the Right Tool for the Right Job

If you work with security systems, APIs, or regulated data, you have probably come across two terms: HMAC and Digital Signatures. Both are used to check that a message has not been changed and that it came from the right source. But they work in very different ways, rely on different cryptographic foundations, and are suited to different situations entirely. Picking the wrong one can create serious security and compliance problems that are not always obvious until something goes wrong.

HMAC, which stands for Hash-based Message Authentication Code, is a symmetric mechanism. It uses a shared secret key to generate a code that both the sender and receiver can verify. It is fast, lightweight, and well suited to internal systems where both sides already trust each other. Digital Signatures, on the other hand, use asymmetric cryptography, meaning a private key to sign and a public key to verify. That separation is what makes them suitable for situations where trust needs to be established and proven to parties outside the original exchange.

The choice between them is not just technical. It has direct implications for non-repudiation, regulatory compliance, audit readiness, and how your system handles accountability when something is disputed. This blog explains what each one does, how they differ, and when to use each.

Quick Answer: HMAC vs. Digital Signatures

HMAC uses a shared symmetric secret key for fast message authentication between parties that already trust each other. It does not provide non-repudiation. Digital Signatures use an asymmetric public/private key pair; any party with the public key can verify the signature, and only the private key holder can produce it. Digital Signatures are required whenever non-repudiation, external verification, or regulatory compliance is at stake.

Key Takeaways

• HMAC (defined in NIST FIPS 198-1) and Digital Signatures (defined in NIST FIPS 186-5, finalized February 3, 2023) both authenticate messages and verify integrity, but they solve different problems. HMAC is the right tool for fast, internal authentication between parties sharing a secret. Digital Signatures are the right tool when non-repudiation, external verification, or legal defensibility is required. Using the wrong mechanism for the context is a compliance and accountability failure, not just a technical mistake.
• Non-repudiation is the critical distinction. Because HMAC uses a shared symmetric secret, either party could have produced the authentication tag; there is no cryptographic proof of who originated the message. Digital Signatures use a private key that only the signer holds, so a verified signature is proof of origin that holds up in audits, legal proceedings, and regulatory reviews. HIPAA, eIDAS, SOX, and PCI DSS each have workflows that require Digital Signatures specifically because of this property.
• NIST FIPS 186-5 (finalized February 3, 2023) specifies RSA-PSS, ECDSA (P-256, P-384, P-521), and EdDSA (Ed25519, Ed448) as approved Digital Signature algorithms. SHA-1-based signatures and RSA signatures under 2048-bit key sizes are deprecated per NIST SP 800-131A Rev. 2. Organizations using Digital Signatures must audit their signing operations against the current approved algorithm list and plan migration to post-quantum algorithms (ML-DSA per NIST FIPS 204, finalized August 13, 2024) on the NIST IR 8547 deprecation timeline.
• Digital Signatures depend on valid, unexpired certificates issued by a trusted Certificate Authority. If the signing certificate expires and is not renewed, signatures produced after expiry are no longer verifiable by relying parties. Certificate lifecycle management is the operational foundation that keeps Digital Signature infrastructure working, and the CA/Browser Forum SC-081v3 validity reduction schedule (47 days by March 15, 2029) means automated renewal via CertSecure Manager is increasingly necessary to prevent signing infrastructure outages.
• Many well-built systems use both mechanisms correctly: HMAC for high-volume internal API authentication and session integrity where shared trust already exists, and Digital Signatures for document signing, audit logs, code signing, and data exchanged across organizations or regulatory boundaries. The two are not in competition; they serve complementary roles. For post-quantum algorithm migration planning for both HMAC and Digital Signature operations, track requirements through the PQC Center of Excellence.

Who Should Care About the HMAC vs. Digital Signature Decision

The choice between HMAC and Digital Signatures is not a single team’s decision. Security architects own the mechanism selection, but PKI teams, compliance teams, platform engineers, and CISOs all have distinct accountabilities in ensuring the right mechanism is used for the right workflow and that the infrastructure supporting each is properly maintained.

Role	Why It Matters	Action Item
Security Architects	Own the mechanism selection decision for each workflow: mapping the authentication, integrity, and non-repudiation requirements of each use case against HMAC or Digital Signature capabilities; documenting the rationale for each decision; and ensuring that workflows requiring non-repudiation use Digital Signatures and not HMAC; must also plan algorithm transitions as NIST FIPS 186-5 deprecates older algorithms and NIST FIPS 204 (ML-DSA, finalized August 13, 2024) becomes the post-quantum replacement for ECDSA-based Digital Signatures	Inventory all workflows using HMAC and Digital Signatures and classify each by non-repudiation requirement; confirm non-repudiation-required workflows use Digital Signatures with certificates issued under a trusted CA hierarchy; flag any workflow using HMAC where regulatory or legal accountability is required and initiate migration to Digital Signatures; conduct a PQC readiness assessment through PQC Readiness services to classify current Digital Signature algorithm exposure against NIST IR 8547 deprecation milestones
PKI and Certificate Teams	Own the infrastructure that makes Digital Signatures operational: the CA hierarchy design, key pair issuance, certificate lifecycle management, revocation infrastructure (OCSP and CRL), and the CP/CPS documentation that makes signatures legally defensible; if the signing certificate expires and is not renewed, signatures produced after expiry are no longer verifiable; the CA/Browser Forum SC-081v3 validity reduction schedule (47 days by March 15, 2029) makes automated certificate renewal mandatory for signing infrastructure	Add all Digital Signature certificates to CertSecure Manager with automated renewal and real-time expiry monitoring; verify revocation infrastructure (OCSP responders and CRL distribution points) is operational and tested; maintain CP/CPS documentation current against regulatory requirements; plan algorithm migration for Digital Signature operations from ECDSA to ML-DSA (NIST FIPS 204) on the NIST IR 8547 timeline; use CBOM Secure to discover which HMAC and Digital Signature algorithms are in use across the enterprise estate
Platform and DevOps Teams	Own the implementation: integrating HMAC for internal APIs and high-volume service-to-service authentication where shared trust already exists, and Digital Signatures for external, regulated, or legally significant workflows; responsible for HMAC shared secret rotation in production, secrets management platform integration (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), and ensuring that Digital Signature verification is integrated into application workflows rather than bypassed for development convenience	Implement HMAC shared secret rotation on a defined schedule (quarterly minimum for production secrets); confirm Digital Signature verification is enforced in all workflows that require it and is not bypassed in any environment; integrate HMAC and Digital Signature operations with secrets management and PKI platforms; add certificate expiry monitoring for all signing certificates to platform observability alerting; confirm post-quantum algorithm migration is included in the platform roadmap
Compliance Teams	Must map each regulated workflow to the authentication and non-repudiation mechanism it requires and verify that the deployed mechanism satisfies the requirement: HIPAA requires audit log integrity and authentication of covered transactions; eIDAS requires qualified Digital Signatures for specific legal document types; PCI DSS 4.0 Requirement 10 requires tamper-evident audit logs with authentication; SOX requires authenticated financial transaction records; HMAC does not satisfy any requirement that specifies Digital Signatures or non-repudiation specifically	Map all regulated workflows to their specific authentication and non-repudiation requirements; confirm Digital Signatures are used wherever regulations specify non-repudiation or where a qualified or advanced electronic signature is required; include HMAC shared secret rotation status and Digital Signature certificate health in the quarterly compliance evidence package; document the algorithm compliance review against NIST FIPS 186-5 approved algorithms (RSA-PSS, ECDSA, EdDSA); confirm deprecated algorithms (SHA-1-based signatures, short RSA keys) are not in use
CISOs	HMAC used where Digital Signatures are required is a compliance and accountability risk that may not surface until a regulatory audit or legal dispute; the DigiCert Trust Pulse Survey (July 2, 2025) found 45 percent of enterprises experienced certificate-related downtime in the prior year, and signing certificate expiry is a direct contributor; post-quantum migration of Digital Signature algorithms (from ECDSA to ML-DSA per NIST FIPS 204) is a strategic program requirement with federal deprecation of RSA and ECC after 2030 per NIST IR 8547	Require a documented inventory of all workflows using HMAC versus Digital Signatures with non-repudiation classification as a board-level KPI; fund Digital Signature infrastructure as a governed, continuously maintained program including PKI hierarchy, CLM platform, and CP/CPS documentation; evaluate PKI as a Service for organizations that need a fully managed signing infrastructure with built-in DR and compliance support; mandate post-quantum algorithm migration planning for Digital Signature operations; track migration progress through the PQC Center of Excellence

What Are HMAC and Digital Signatures?

Both HMAC and Digital Signatures are types of Message Authentication Codes (MACs). A MAC is a short piece of information used to confirm that a message is genuine and has not been tampered with. But how they do this is quite different.

HMAC, which stands for Hash-based Message Authentication Code, uses Symmetric Authentication. This means both the sender and the receiver use the same shared secret key. The message and the key are run through a hash function, such as SHA-256, to produce a tag. Anyone who has the shared secret can create or check this tag.

Digital Signatures use Asymmetric Cryptography, which means two different keys are involved: a private key and a public key. The sender signs the message using their private key, and anyone with the matching public key can verify the signature. The private key stays with the sender at all times.

A simple way to think about it: HMAC is like a lock that two people share a key to. Digital Signatures are more like a personal stamp that only one person can make, but anyone can recognize.

How HMAC Provides Symmetric Message Authentication

HMAC combines the message with a secret key and passes them through a hash function. This produces a unique tag. Here is what makes HMAC useful:

• The tag cannot be guessed or recreated without knowing the secret key.
• If even one character in the message changes, the tag changes completely.
• An attacker cannot create a valid tag without the shared secret.

This makes HMAC very good at ensuring Data Integrity and Authentication in systems where both sides already know the same secret. It is commonly used in API authentication tokens, session cookies, and webhook verification.

HMAC is also very fast. Because it uses Symmetric Authentication, it handles large volumes of requests quickly. This is useful for systems that process millions of requests per minute.

However, HMAC has a key limitation. Because both sides share the same secret, either one could have created the tag. There is no way to prove to a third party which side sent the message. This is where non-repudiation becomes important, and HMAC simply cannot provide it.

How Digital Signatures Enable Asymmetric Trust

Digital Signatures solve a different problem. What if you need to prove to someone who has never met you that a message came from you and was not changed? That is exactly what Digital Signatures are built for.

The process works like this:

• The sender creates a hash of the message.
• That hash is encrypted using the sender’s private key. The result is the Digital Signature.
• The receiver decrypts the signature using the sender’s public key, creates their own hash of the received message, and compares the two. If they match, the message is authentic and unchanged.

Because only the owner of the private key can create the signature, this setup allows external verification without sharing any secrets. Public Key Cryptography makes this possible.

This is the foundation of PKI (Public Key Infrastructure), TLS/SSL certificates, code signing, and document authentication systems used in regulations like eIDAS or US federal standards.

HMAC vs. Digital Signatures: A Feature-by-Feature Comparison

Here is how the two mechanisms compare across the features that matter most:

Feature	HMAC	Digital Signatures
Key Type	Shared symmetric secret key	Asymmetric public/private key pair
Authentication	Confirms message integrity and sender identity (between parties sharing the secret)	Confirms message integrity and sender identity (verifiable by any party with the public key)
Non-Repudiation	Not provided: either party holding the shared secret could have produced the tag	Provided: only the private key holder can produce a valid signature
Performance	Very fast: symmetric hash operations only	Slower: asymmetric key operations (RSA-PSS, ECDSA, EdDSA)
Key Management	Shared secret only; simpler to manage but requires secure distribution to both parties	Full PKI infrastructure: Certificate Authority, key pairs, certificate lifecycle management, revocation
Third-Party Verification	Not possible without sharing the secret (which defeats security)	Any party with the public key can verify, without any secret being shared
Standard	NIST FIPS 198-1 (The Keyed-Hash Message Authentication Code)	NIST FIPS 186-5 (Digital Signature Standard, finalized February 3, 2023): RSA-PSS, ECDSA, EdDSA
Best Use Case	Internal APIs, session tokens, webhook verification, high-volume service-to-service integrity checks	Document signing, audit logs, code signing, cross-organization data exchange, regulated transactions

• Key Type: HMAC uses a shared secret key (Symmetric). Digital Signatures use a public and private key pair (Asymmetric Cryptography).
• Authentication: Both HMAC and Digital Signatures confirm the identity of the sender.
• Non-Repudiation: HMAC does not provide this. Digital Signatures do.
• Performance: HMAC is very fast. Digital Signatures are slower due to the complexity of asymmetric operations.
• Key Management: HMAC requires only a shared secret, which is simple to manage. Digital Signatures require PKI infrastructure.
• Third-Party Verification: HMAC cannot be verified by a third party without sharing the secret. Digital Signatures can be verified by anyone using the public key.
• Best Use Case: HMAC suits internal APIs and session tokens. Digital Signatures suit contracts, audit logs, and cross-organization exchanges.

These two tools are not in competition. They are designed for different situations. Knowing which one fits your needs is what matters.

Why Non-Repudiation Requires Digital Signatures

Non-Repudiation means a sender cannot later deny having sent a message. It is a critical property in legal, financial, and regulated environments. Think of it as the digital version of a signed contract.

HMAC does not support non-repudiation. Since both parties hold the same key, either one could have created the tag. In a dispute, there is no way to tell which side produced it. This makes HMAC unsuitable when accountability matters.

Digital Signatures do provide non-repudiation. Since only the private key holder can produce a valid signature, a verified Digital Signature is proof of who created the message. This holds up in formal investigations, audits, and legal proceedings.

This is why industries like healthcare (HIPAA), finance, and legal services require Digital Signatures for sensitive documents. It is also the reason code signing uses Digital Signatures: a software package with a verified signature from a trusted publisher is much safer to install.

HMAC vs. Digital Signatures: Use-Case Decision Matrix

Use this matrix to map your specific workflow against the right mechanism. The key variable is whether non-repudiation and external verifiability are required. If the answer to either is yes, Digital Signatures are required regardless of the performance or infrastructure cost.

Use Case	Non-Repudiation Required	Recommended Mechanism	Security Impact of Wrong Choice	Operational Effort	Owner
Internal API authentication (service-to-service, same trust boundary)	No	HMAC (SHA-256 or SHA-384)	Low: both parties share trust; accountability within the system is sufficient	Low: shared secret only; no PKI infrastructure required	Platform/DevOps Team
Webhook payload verification (third-party provider to internal system)	No	HMAC (SHA-256)	Low to Medium: provider sends a shared secret at onboarding; HMAC confirms payload integrity	Low: shared secret per webhook source; rotate on a defined schedule	Platform/DevOps Team
Session integrity and token signing (internal user sessions)	No	HMAC (SHA-256 or SHA-512)	Low: session tokens are short-lived; HMAC provides adequate integrity for the session duration	Low: symmetric operation; no PKI required	Platform/DevOps Team
Audit log integrity (internal systems, no external audit requirement)	No (internal only)	HMAC acceptable; Digital Signatures preferable for future-proofing	Medium: if audit logs are challenged, HMAC cannot prove which party wrote them; Digital Signatures provide stronger evidence	Low to Medium: HMAC is simpler; Digital Signatures require PKI	Security Architect + PKI Team
Regulated audit logs (HIPAA, PCI DSS 4.0 Req. 10, SOX)	Yes	Digital Signatures (ECDSA or EdDSA per NIST FIPS 186-5)	Critical: HMAC does not satisfy non-repudiation requirements; compliance failure and audit finding	Medium to High: requires PKI infrastructure, certificate lifecycle management, signing key protection	PKI Team + Compliance Team
Document signing (contracts, approvals, legal records)	Yes	Digital Signatures (RSA-PSS or ECDSA per NIST FIPS 186-5)	Critical: a signed document without non-repudiation has no legal standing; disputes cannot be resolved cryptographically	High: requires PKI, certificate issuance, CP/CPS documentation, and possibly eIDAS-qualified signatures	PKI Team + Legal/Compliance Team
Code signing (software, firmware, update packages)	Yes	Digital Signatures (ECDSA or EdDSA per NIST FIPS 186-5)	Critical: unsigned or HMAC-authenticated code cannot prove publisher identity to relying parties; software supply chain risk	High: requires code signing certificate from a trusted CA, HSM key protection, certificate lifecycle management	PKI Team + Platform/DevOps Team
Cross-organization data exchange (B2B, partner APIs, EDI)	Yes (external verification required)	Digital Signatures (ECDSA or EdDSA per NIST FIPS 186-5)	High: HMAC requires sharing the secret with the external party, creating a key distribution attack surface; Digital Signatures allow verification with the public key only	Medium to High: requires mutual PKI trust or a shared trust anchor (commercial CA or cross-certification)	Security Architect + PKI Team
TLS/mTLS certificate-based mutual authentication	Yes (client authentication)	Digital Signatures (ECDSA or EdDSA in certificate; RSA-PSS acceptable)	Critical: TLS uses Digital Signatures for the certificate chain; HMAC is not applicable to certificate-based authentication	High: requires PKI infrastructure, private CA or public CA, certificate lifecycle management via CertSecure Manager	PKI Team

Choosing Between HMAC and Digital Signatures

The right choice depends on your specific situation. Ask yourself these questions:

• Do both sides already share a secret? If yes, HMAC is simpler and faster. If not, or if external parties need to verify the message, use Digital Signatures.
• Is non-repudiation required? If compliance, legal review, or audits are involved, Digital Signatures are the right choice.
• Does performance matter? HMAC is significantly faster. For high-volume internal systems, it is usually the more practical option.
• Is PKI infrastructure available? Digital Signatures require a key pair and often a Certificate Authority (CA). If your organization does not have this yet, HMAC may be a practical short-term solution, but building toward PKI is the right long-term direction.

Many well-built systems use both: HMAC for fast internal API authentication, and Digital Signatures for document signing, audit logs, and data exchanged across organizations. They are not alternatives; they serve different roles.

How Encryption Consulting Can Help

Digital Signatures require PKI infrastructure to work properly, and for many organizations, that is exactly where the gap sits. Not in understanding which tool to use, but in having the foundation in place to use it. Encryption Consulting’s PKI Services are built to close that gap.

Whether your organization is starting from scratch or working with an existing setup that needs to be strengthened, our team designs and implements PKI infrastructure that supports Digital Signatures, certificate-based identity authentication, and the non-repudiation requirements that regulated industries demand.

Here is what our PKI Services cover:

PKI Assessment: We evaluate where your organization currently stands, identify whether your existing infrastructure can support Digital Signatures at the scale you need, and produce a clear roadmap for closing any gaps.

PKI Design and Implementation: We design a Certificate Authority hierarchy tailored to your organization, backed by FIPS 140-3 compliant HSMs where required, so your private keys are protected, and your Digital Signatures hold up to scrutiny.

CP/CPS Development: We document the Certificate Policies and Certification Practice Statements that define how your PKI operates, which is essential for regulated industries like healthcare, finance, and legal services where the integrity of Digital Signatures must be provable.

Certificate Lifecycle Management: Every public and private key pair has a lifecycle. We implement the processes and tooling, including CertSecure Manager, to manage issuance, renewal, and revocation so your Digital Signature infrastructure stays current and compliant over time. For organizations that need a fully managed PKI layer with built-in DR and compliance support, PKI as a Service shifts the operational responsibility to our team.

Organizations that rely on HMAC alone for workflows that require non-repudiation are carrying a compliance risk they may not have fully mapped. If your environment needs to move toward Digital Signatures, or if you need to make sure your existing PKI infrastructure is solid enough to support that, our team is ready to help. Use CBOM Secure to discover which HMAC and Digital Signature algorithms are currently in use across your estate before planning any migration or compliance remediation.

Conclusion

HMAC and Digital Signatures both protect data, but they do so in different ways and for different purposes. HMAC relies on Symmetric Authentication and a shared secret. It is fast and practical for internal use. Digital Signatures rely on Asymmetric Cryptography and Public Key Cryptography. They provide non-repudiation and are essential for regulated, external, or legally significant workflows.

Using the wrong tool for the wrong job is a real risk. HMAC used where Digital Signatures are required can fail a compliance audit or leave your organization unable to prove accountability. Getting this right from the start is far easier than fixing it later.

Frequently Asked Questions

What is the main takeaway from HMAC vs. Digital Signatures: Understanding the Right Tool for the Right Job?

HMAC and Digital Signatures both authenticate messages and verify integrity, but they solve different problems. HMAC is a symmetric mechanism using a shared secret key; it is fast and suited to internal systems where both parties already trust each other, but it cannot prove to a third party which side originated the message. Digital Signatures are an asymmetric mechanism using a private key to sign and a public key to verify; they provide non-repudiation and are required when accountability must be provable in audits, legal proceedings, or cross-organization data exchange. Using HMAC where Digital Signatures are required is a compliance and accountability failure.

Why does this matter for enterprise PKI teams?

Enterprise PKI teams are responsible for the infrastructure that makes Digital Signatures possible: the Certificate Authority hierarchy, key pair issuance and lifecycle management, certificate revocation, and the CP/CPS documentation that makes signatures legally defensible. NIST FIPS 186-5 (finalized February 3, 2023) specifies RSA-PSS, ECDSA, and EdDSA as approved digital signature algorithms; PKI teams must ensure their CA infrastructure supports the approved algorithms and transitions away from deprecated ones on the NIST IR 8547 timeline.

What risks increase if HMAC is used where Digital Signatures are required?

Three specific risk categories increase. First, non-repudiation failure: if a workflow requires proof of origin and HMAC is used, either party could deny having sent the message. Second, compliance audit failure: HIPAA, eIDAS, SOX, and PCI DSS each have workflows that require Digital Signatures; HMAC does not satisfy these requirements. Third, accountability gaps in incident response: when a security incident requires determining which party authorized a transaction, HMAC-authenticated records cannot establish individual accountability.

Which teams should own the decision between HMAC and Digital Signatures?

Security architects own the mechanism selection for each workflow. PKI teams own the infrastructure that makes Digital Signatures operational. Compliance teams own the regulatory mapping that determines which workflows require Digital Signatures. Platform and DevOps teams own the implementation: integrating HMAC for internal APIs where appropriate and Digital Signatures for external, regulated, or legally significant workflows.

How does this connect to certificate lifecycle management?

Digital Signatures depend on valid, unexpired certificates issued by a trusted Certificate Authority. If a signing certificate expires and is not renewed, signatures produced after expiry are no longer verifiable. CertSecure Manager provides the CLM layer that keeps Digital Signature infrastructure operational, with automated renewal and real-time expiry monitoring across public and private CA populations.

How should organizations measure success in HMAC and Digital Signature governance?

Key metrics: workflow coverage (percentage of non-repudiation-required workflows documented as using Digital Signatures, with zero exceptions in regulated contexts); certificate health for signing infrastructure (zero expired or revoked certificates in active use for Digital Signature workflows); algorithm compliance (all Digital Signature operations using NIST FIPS 186-5 approved algorithms: RSA-PSS, ECDSA, or EdDSA; no deprecated algorithms in production); and audit evidence completeness (ability to produce a full transaction log with Digital Signature records on demand).

What should be audited or monitored regularly?

Monitor continuously: certificate expiry for all signing certificates with renewal alerts at 30 percent of remaining validity; revocation status of signing certificates via OCSP or CRL. Audit quarterly: inventory of all workflows using HMAC versus Digital Signatures, verifying non-repudiation-required workflows use Digital Signatures; HMAC key rotation status; algorithm classification against NIST FIPS 186-5 approved algorithms. Audit annually: CP/CPS documentation currency; Digital Signature legal defensibility review for jurisdiction-specific requirements.

How does this affect cloud, hybrid, or multi-CA PKI environments?

Cloud and hybrid environments add complexity on three dimensions: HMAC shared secret distribution (must be rotated across services without exposure using secrets management platforms); multi-CA Digital Signature trust (relying parties must trust the issuing CA or a trusted root above it); and post-quantum migration (ECDSA-based Digital Signatures will need to migrate to ML-DSA per NIST FIPS 204, finalized August 13, 2024, on the NIST IR 8547 deprecation timeline).

What common mistakes should teams avoid?

The most frequent mistakes: using HMAC for workflows requiring non-repudiation because it is simpler to implement; assuming HMAC satisfies compliance requirements without verifying the specific regulatory text; not rotating HMAC shared secrets on a defined schedule; not maintaining the PKI infrastructure that Digital Signatures depend on (expired signing certificates, untested revocation infrastructure, outdated CP/CPS); and not inventorying which workflows use which mechanism, making compliance exposure and algorithm migration planning impossible.

What should be refreshed quarterly?

Quarterly: audit the inventory of workflows using HMAC versus Digital Signatures and confirm non-repudiation-required workflows use Digital Signatures; verify HMAC shared secret rotation for all production secrets; confirm all Digital Signature certificates are current with adequate renewal lead time; review algorithm classification against NIST FIPS 186-5; and classify Digital Signature certificate populations against NIST post-quantum deprecation milestones (ML-DSA per FIPS 204, finalized August 13, 2024). For post-quantum algorithm migration planning, check the PQC Center of Excellence.