Why digital signatures matter

Organizations signing contracts, compliance documents, medical records, and financial agreements need assurance that signed documents are authentic, unaltered, and legally enforceable.

Digital signatures provide this assurance through cryptographic technology that verifies:

• Document integrity — The document hasn’t been modified since signing
• Author authenticity — The signer’s identity is verified and confirmed
• Non-repudiation — The signer cannot deny having signed the document
• Timestamp verification — Proof of when the document was signed

This guide covers implementing digital signatures, from understanding the standards (PAdES, CAdES, XAdES), to meeting compliance requirements and building production-ready signing workflows.

Electronic signatures vs. digital signatures

Electronic signatures and digital signatures are different technologies with different security properties, though the terms are often used interchangeably.

Electronic signatures (eSignatures)

An electronic signature is a digital representation of a handwritten signature. It can be as simple as:

• A typed name in a signature field
• A drawn signature using a mouse, stylus, or finger
• An uploaded image of a handwritten signature
• A checkbox indicating agreement

Digital signatures

A digital signature is a cryptographic solution that produces a verifiably untampered document. It uses public key infrastructure (PKI) to create an encrypted “digital fingerprint” tied to a signer’s identity.

Digital signatures provide:

• Authentication — Precise identification of the signer via X.509 certificates
• Integrity — Detection of any post-signing modifications through hashing
• Non-repudiation — The signer cannot deny their signature once applied

Comparison table

Understanding signature standards: PAdES, CAdES, and XAdES

The European Telecommunications Standards Institute (ETSI)(opens in a new tab) has defined three primary standards for advanced electronic signatures. Each standard is designed for specific use cases and file formats.

PAdES (PDF Advanced Electronic Signatures)

PAdES(opens in a new tab) is the standard specifically designed for PDF documents, defined in ETSI EN 319 142. It defines extensions to standard electronic signatures that make them compliant with legislative requirements worldwide.

Key characteristics of PAdES

• Embedded in PDF files — signatures are part of the document itself
• Supports visible and invisible signatures
• Allows multiple signatures on a single document
• Compatible with standard PDF readers
• Supports timestamping and long-term validation (LTV)

PAdES compliance levels

PAdES defines four progressive compliance levels(opens in a new tab), each building on the previous one.

CAdES (CMS Advanced Electronic Signatures)

CAdES(opens in a new tab) is based on the Cryptographic Message Syntax (CMS)(opens in a new tab) and can be applied to any type of file, not just PDFs.

Key characteristics of CAdES

• File-agnostic — Can sign any file type (PDF, images, XML, etc.)
• Wraps the signed file in a .p7m container that includes both the file and its signature
• Requires specialized software to view and validate
• Doesn’t support visible signatures

XAdES (XML Advanced Electronic Signatures)

XAdES(opens in a new tab) is designed for XML documents and is commonly used in web services, electronic invoicing, and government systems.

Key characteristics of XAdES

• Based on the XML Digital Signature (XMLDSig)(opens in a new tab) standard
• Signature is expressed in XML format
• Can be embedded (enveloped), contain data (enveloping), or reference external data (detached)
• Commonly used in SOAP web services and eInvoicing (e.g. UBL, Factur-X)

Standard comparison

Global compliance frameworks

Digital signatures are legally binding in most jurisdictions when they comply with applicable regulations.

eIDAS (European Union)

The Electronic Identification, Authentication and Trust Services (eIDAS)(opens in a new tab) regulation establishes the legal framework for electronic signatures in the EU. It defines three levels of electronic signatures:

• Simple Electronic Signature (SES) — Basic eSignature with no specific requirements. Legally valid but offers minimal security.
• Advanced Electronic Signature (AdES) — Linked to the signer, created with keys only they control, and detects any changes to the signed data.
• Qualified Electronic Signature (QES) — An AdES created using certified hardware and a qualified certificate from a trusted provider. Legally equivalent to a handwritten signature.

PAdES fully supports eIDAS compliance. Nutrient integrates with trusted certificate authorities like GlobalSign to enable QES signatures.

ESIGN Act (United States)

The Electronic Signatures in Global and National Commerce (ESIGN) Act(opens in a new tab) provides the federal framework for electronic signatures in the US. Key requirements include:

• Intent to sign — The signer must demonstrate clear intent to sign
• Consent to electronic records — Parties must agree to conduct business electronically
• Record retention — Signed records must remain accessible and reproducible
• Attribution — The signature must be attributable to a specific individual

UETA (US state level)

The Uniform Electronic Transactions Act (UETA)(opens in a new tab) complements ESIGN at the state level. It has been adopted by 49 states, the District of Columbia, Puerto Rico, and the U.S. Virgin Islands. New York has not adopted UETA but has its own electronic signature statute (ESRA).

FDA 21 CFR Part 11 (pharmaceutical/medical)

For pharmaceutical and medical device industries, the FDA’s 21 CFR Part 11(opens in a new tab) governs electronic records and signatures. Requirements include:

• Complete audit trails for all document changes
• Signature manifestations showing printed name, date/time, and meaning
• Unique identification of each signer
• System access controls and security procedures

Implementing digital signatures with Nutrient

Nutrient offers digital signature capabilities across multiple products for different deployment models.

Digital signatures across Nutrient products

Signature architecture options

Nutrient supports three primary signing architectures, each suited to different security and deployment requirements:

1. Client-side signing — Certificates stored locally or in hardware tokens. Best for scenarios where private keys must never leave the user’s device.
2. Server-side signing — Centralized signature servers or cloud services. Ideal for automated workflows and batch signing.
3. Delegated signing — Clients send only document hashes to a secure backend with a hardware security module (HSM). Private keys stay protected while users sign.

Prerequisites

Before implementing digital signatures with Nutrient, ensure you have:

• A Nutrient SDK license (for client-side signing) or a Document Engine instance (for server-side signing)
• Node.js 18+ (for JavaScript examples)
• A PDF document to sign
• A signing certificate in PKCS#12 format (or use Nutrient’s GlobalSign integration for QES)

Code example: Signing with PAdES B-LT

The following example demonstrates signing a PDF with long-term validation using Nutrient’s Digital Signatures API:

curl -X POST https://api.nutrient.io/sign \
  -H "Authorization: Bearer your_api_key_here" \
  -o result.pdf \
  --fail \
  -F file=@document.pdf \
  -F data='{
      "signatureType": "cades",
      "cadesLevel": "b-lt"
    }'

This creates a PAdES B-LT signature with long-term validation data embedded, ensuring the signature remains verifiable even after the signing certificate expires.

Web SDK example

For client-side signing with the Web SDK:

await instance.signDocument(
  {
    signingData: {
      signatureType: NutrientViewer.SignatureType.CAdES,
      padesLevel: NutrientViewer.PAdESLevel.b_lt,
    },
  },
  {
    jwt: "<access_token>",
  }
);

Signature validation

Nutrient’s validation process consists of two steps:

1. Certificate trust verification — Checks if the signature certificate can be trusted by validating against provided root certificates.
2. Signature integrity verification — Decrypts the signature using the public key and compares the result with the document’s hash to detect any modifications.

The validation UI displays a color-coded status: green for valid, yellow for warnings, and red for invalid signatures.

Validation status in Web SDK

const signaturesInfo = await instance.getSignaturesInfo();
console.log("Overall status:", signaturesInfo.status);
// NutrientViewer.DocumentValidationStatus.valid
// NutrientViewer.DocumentValidationStatus.warning
// NutrientViewer.DocumentValidationStatus.error
signaturesInfo.signatures.forEach((sig) => {
  console.log("PAdES Level:", sig.PAdESSignatureLevel);
  console.log("Valid from:", sig.validFrom);
  console.log("Valid until:", sig.validUntil);
  console.log("Certificate chain status:", sig.certificateChainValidationStatus);
});

GlobalSign integration

For trusted digital signatures meeting eIDAS regulations, Nutrient integrates with GlobalSign DSS:

await instance.signDocument(
  {
    signingData: {
      signatureType: NutrientViewer.SignatureType.CAdES,
      padesLevel: NutrientViewer.PAdESLevel.b_lt,
    },
  },
  {
    signingToken: jwtToken,
  }
);

Long-term validation (LTV)

LTV (PAdES B-LT) ensures a signature remains verifiable years after signing by embedding validation data at signing time. This addresses scenarios where:

• The signer’s certificate has expired
• The Certificate Authority has ceased operations
• Online revocation services are no longer available

How LTV works

LTV works by embedding all the data needed to validate a signature at the time of signing. This includes:

• Complete certificate chain — From the signer’s certificate to the trusted root
• Revocation status — Proof that the certificate wasn’t revoked at signing time (fetched from online services)
• Trusted timestamp — Cryptographic proof of when the document was signed

Implementing LTV with Nutrient

Nutrient handles LTV when you specify the appropriate PAdES level. For PAdES B-LT signatures, Nutrient will:

1. Contact the OCSP server to obtain revocation status for certificates
2. Embed the certificate chain needed for validation
3. Include cryptographic timestamp tokens when timestamping is enabled
4. Store all validation data within the PDF document

PAdES level selection guide

Best practices

This section covers security guidelines for key management and certificate handling, along with a checklist to complete before deploying to production.

Security

• Use RSA 2048-bit+ keys (or ECDSA) and SHA-256 or stronger
• Store private keys in HSMs or secure key vaults, never in application code
• Obtain certificates from recognized CAs and monitor expiration
• Use HTTPS for all communications

Before going to production

• Identify applicable regulations (eIDAS, ESIGN, FDA, etc.)
• Choose the appropriate PAdES level based on retention requirements
• Configure trusted root certificates for validation
• Implement audit logging
• Test validation across PDF readers and browsers

FAQ

Conclusion

Digital signatures provide cryptographic verification, legal enforceability, and long-term document integrity for compliance-critical workflows. By understanding the standards (PAdES for PDFs, CAdES for any file, XAdES for XML) and compliance frameworks (eIDAS, ESIGN, FDA 21 CFR Part 11), you can build signing solutions that meet your organization’s requirements.

Additional resources

• Digital signatures implementation guide
• Cryptography standards for PDF signatures
• GlobalSign integration for QES

Explore related topics