# Trusted Signatures

> Generated canonical source corpus for implementation-path selection, product fit, pricing, trust review, and legal/data-handling diligence.

This file is generated from selected Hugo source pages. It preserves canonical URLs and extracts readable summaries, highlights, and FAQs from the strongest factual pages.

## Documentation

Canonical URL: https://trusted-signatures.com/docs/
Source Path: content/docs/_index.md

Summary: Quickstart guides for API, CLI, Web sealing, Zapier, and cloud connector workflows. Choose self-serve implementation or book a technical walkthrough.

### Highlights

- API + CLI + Web sealing + Zapier + Cloud Connectors
- No file upload
- Acrobat-visible trust
- Use the signing endpoint to request CMS signatures from your own PDF digest workflow.
- Best for product teams embedding document trust directly into existing services.
- Use sign-pdf for CI/CD pipelines and operational workflows.
- Best for teams shipping signed PDFs from scripts or backend jobs.
- Seal PDFs directly in your browser while keeping the document on the local device.
- Best for teams that want the fastest no-upload path to a sealed PDF.
- Use no-code workflow triggers to seal documents from the tools your team already uses.

## Trusted PDF sealing for every compliance level

Canonical URL: https://trusted-signatures.com/pricing/
Source Path: content/pricing.md

Summary: Flexible pricing for Publisher: usage-based options for workflows and web, plus subscription licensing for cloud platforms like Azure and AWS. Identity add-ons are available for AATL and EU Advanced trust paths so Acrobat/Reader show the right trust banners.

### Highlights

- AATL/EUTL options
- Transparent pricing for sealing, identity, and validator add-ons. No hidden fees.
- Pay-as-you-go sealing
- Optional AATL / EU Advanced OrgIDs
- HSM-backed keys and logs
- Each signature is billed at its tier's rate, with cumulative pricing. Subscribers can view a live usage log anytime, and usage history is available on the secure billing page.
- This structure rewards higher volumes while keeping costs transparent and predictable. You're never locked into a flat rate-your pricing adjusts automatically based on real usage.
- We designed this model to be fair, flexible, and aligned with how your business grows. If you ever have questions about billing or usage, our support team is here to help.
- Additional taxes may apply in non-US jurisdictions.
- Trusted Signatures pricing starts with usage-based Publisher sealing for teams that want to move quickly without annual platform licensing. If you need your own organization shown in Acrobat trust banners, add Publisher Identity on an annual term for either AATL OrgID or EU Advanced OrgID.
- Best for self-serve teams: start with Publisher, validate in your own workflow, then scale with volume tiers.
- Best for regulated or buyer-reviewed rollouts: pair Publisher with Identity and an assisted implementation path.
- What you do not pay for: document upload, per-seat licensing, or a mandatory long-term contract for Publisher.
- Web sealing pricing: browser-based sealing uses the same Publisher usage pricing as CLI and API sealing.

## Trust & Security

Canonical URL: https://trusted-signatures.com/docs/trust/
Source Path: content/docs/trust.md

Summary: Trusted Signatures Trust & Security: no PDF storage, hash-only sealing, FIPS-validated HSMs, AWS U.S. hosting, GDPR/CPRA aligned.

### Highlights

- Effective Date: 10/31/2025
- Last Updated: 10/31/2025
- Trusted Signatures ("TS") is built to minimize data exposure: we don't upload or store your PDFs. Our service operates on non-reversible SHA-256 digests and certificate status data to apply standards-based seals.
- No PDF storage. We do not ingest, store, or inspect document content or filenames.
- Hash-only workflow. We process SHA-256 digests, timestamps, and certificate status (OCSP/CRL) required for signing/verification.
- Hosted in the U.S. Infrastructure runs on AWS U.S. (Central).
- Encryption. TLS in transit; encryption at rest where applicable.
- Access control. SSO/MFA, role-based access (RBAC), least privilege, audited admin actions.
- Key management. Signing keys are protected by FIPS 140-3 Level 3-validated HSMs; keys are generated, stored, and used within the cryptographic boundary.
- Monitoring. Centralized logging and metrics via AWS CloudWatch; alerting and incident response runbooks.
- SDLC & vulnerability management. Code review, dependency scanning, secrets management, periodic penetration testing.
- Business continuity. Backups, redundancy, and disaster-recovery objectives for critical systems.
- Trusted Signatures processes payments through Stripe, a PCI DSS Level 1–certified provider. We never store or transmit cardholder data on our own systems. All credit-card transactions and billing data are handled securely by Stripe.
- Our cryptographic operations run inside FIPS 140-3 Level 3–validated hardware security modules (HSMs). This ensures that signing keys are generated, stored, and used entirely within a tamper-resistant, validated boundary.
- Our hosting and infrastructure providers (e.g., AWS) maintain SOC 2 Type II certification for operational security, data availability, and confidentiality controls. Trusted Signatures inherits these assurances as part of its secure cloud deployment.
- ISO 27001 is the international standard for managing information security. It provides a framework for how an organization protects data, controls access, and monitors risks.
- Trusted Signatures follows ISO 27001-aligned practices through its cloud providers and internal controls, ensuring operational security complements our product’s compliance with ISO 32000, the open standard that defines the PDF format itself.
- Trusted Signatures is a controller for account/billing/support and a processor/service provider for limited operational data (e.g., digests, logs, certificate status). We comply with EU data-protection requirements for customer information. All personal or organizational data collected for identity verification or billing is processed under GDPR lawful-use and retention principles. See our Privacy Policy. Contact us to request a DPA, and Subprocessor List.

## Frequently Asked Questions

Canonical URL: https://trusted-signatures.com/docs/faq/
Source Path: content/docs/faq.md

Summary: Comprehensive FAQ about PDF digital signatures, AATL certificates, eIDAS compliance, pricing, API integration, and security.

### Highlights

- Trusted Signatures is the document-trust layer that connects cybersecurity controls to legal rigor and financial protection. We apply PKI-based, standards-compliant PDF seals that are tamper-evident and auditable, so critical files hold up in reviews, audits, and cash-flow processes. (Built on ISO 32000 PDF signatures with DocMDP permissions, legal attestation, timestamping, OCSP/CRL, and version-comparison capabilities.)
- Our mission: Make verifiable documents the default for business — simple, affordable, and ubiquitous.
- Publisher applies an organizational cryptographic seal to your PDFs so recipients can confirm origin and detect any tampering directly in Adobe Acrobat/Reader and other PAdES-aware viewers. Your documents never leave your environment—we sign a cryptographic digest, not your file.
- A certificate-based signature that validates in Acrobat/Reader (blue ceritified experience).
- Clear signer/certificate details; optional restrictions on what can change after sealing
- Document is tamper-evident with clear signer details.
- PAdES-compliant sealing with Long-Term Validation (LTV) options (configurable)
- RFC 3161 timestamping plus embedded OCSP/CRL data for offline verification (configurable)

### FAQs

#### Who is Trusted Signatures?

Trusted Signatures is the document-trust layer that connects cybersecurity controls to legal rigor and financial protection. We apply PKI-based, standards-compliant PDF seals that are tamper-evident and auditable, so critical files hold up in reviews, audits, and cash-flow processes. (Built on ISO 32000 PDF signatures with DocMDP permissions, legal attestation, timestamping, OCSP/CRL, and version-comparison capabilities.) Our mission: Make verifiable documents the default for business — simple, affordable, and ubiquitous.

#### What is Publisher — Trusted PDF Sealing?

Publisher applies an organizational cryptographic seal to your PDFs so recipients can confirm origin and detect any tampering directly in Adobe Acrobat/Reader and other PAdES-aware viewers. Your documents never leave your environment—we sign a cryptographic digest, not your file. What recipients see: - A certificate-based signature that validates in Acrobat/Reader (blue ceritified experience). - Clear signer/certificate details; optional restrictions on what can change after sealing - Document is tamper-evident with clear signer details. Built-in assurances: - PAdES-compliant sealing with Long-Term Validation (LTV) options (configurable) - RFC 3161 timestamping plus embedded OCSP/CRL data for offline verification (configurable) - Non-exportable keys protected by FIPS 140-2/140-3 Level 3 HSMs - DocMDP/Certification profiles to limit post-seal edits (e.g., form-fill only) How it fits your workflow: - Integrate via API, CLI, Web sealing, or Zapier; no uploads required and browser-based sealing keeps the PDF on the local device - Ideal for invoices, statements, reports, and any PDF that must be provably authentic outside an e-signature flow See Pricing to learn more about our pay-as-you-go, no license fees model and use an estimator to predict your costs.

#### What is Publisher Identity - AATL OrgID and EU Advanced OrgID

An annual add-on that issues a dedicated organizational certificate in your organization’s name from an Adobe Approved Trust List (AATL) provider, so your sealed PDFs show your organization as the signer in Acrobat/Reader. EU Advanced OrgID is an annual add-on that issues your business name appear in the seal using an organizational certificate from an EU Trusted Lists (EUTL) Certificate Authority. What recipients see: - In Acrobat/Reader (and other PAdES-aware viewers), recipients see the blue certified signature indicator with your organization listed as the signer. See Pricing to learn more about Identity.

#### How is using an Identity add-on different from Publisher - Trusted PDF Sealing?

Publisher sealing uses our default certificate (OrgID). Identity add-ons put your organization’s identity on the seal while keeping the same API/CLI/Web sealing/Zapier integration. Trust path note: PDFs sealed using Publisher, without an Identity add-on, support eIDAS Advanced electronic seals (AdES) and validate in Acrobat/Reader and other PAdES-aware viewers.

#### Do you store our PDFs?

No. Trusted Signatures does not ingest or store document content or filenames. Our service operates on non-reversible SHA-256 digests and certificate status data (OCSP/CRL, timestamps). Details: Trust and Security

#### What encryption and key protections do you use?

TLS in transit; encryption at rest where applicable; SSO/MFA and RBAC for access control; audit logging via AWS CloudWatch. Signing key material is protected by FIPS 140-validated HSMs (Level 3 where applicable). Controls: Trust and Security

#### Where are you hosted?

We run on AWS U.S. (Central). See hosting and regional details here: Trust and Security.

#### Does Publisher Identity - EU Advanced OrgID meet Qualified seals standards?

We support Advanced Electronic Seals (AdES) with Publisher and Publisher Identity - EU Advanced Org ID services. Qualified Electronic Seals (QSeal) are not available.

#### Do you comply with PCI DSS?

Yes. Trusted Signatures processes payments through Stripe, a PCI DSS Level 1-certified provider. We never store or transmit cardholder data on our own systems. Our focus is on securing your digital documents, not your payment credentials.

#### What data do you retain?

Account/billing data, API/service logs, SHA-256 digests, and certificate/validation status data necessary to operate the Service. Current retention windows are published in our Privacy Policy.

#### Do you have a DPA?

Yes. Our Data Processing Addendum (DPA) defines roles, security measures, transfers (SCCs/UK addendum), and subprocessor governance. Find it here: Data Processing Addendum.

#### Where can I see your subprocessors?

We maintain a live Subprocessor List with vendor purposes, regions, and safeguards. Updates to that page constitute notice under our DPA. Subprocessors.

#### Do you support HIPAA? Can you sign a BAA?

The Service is not designed to receive PHI. Customers must not send PHI in PDFs, filenames, or support materials. If required, we can execute a limited BAA covering narrowly defined operational metadata such as logs, digests, and certificate status, expressly excluding document content. Overview: Trust and Security. Contact us for more details.

#### What’s the difference between AATL OrgID and EU Advanced OrgID?

AATL OrgID uses a CA recognized on Adobe’s AATL for global Acrobat/Reader trust. EU Advanced OrgID uses an EUTL-listed provider aligned to eIDAS Advanced (AdES) for PAdES. Many recipients will see both validate in Acrobat; on-screen banners depend on the viewer’s trust store and configuration. See validation context in Trust and Security. Contact us for more details.

#### Do you have SOC 2?

Our cloud provider (AWS) maintains SOC 2 Type II and related certifications. We complement this with internal controls including MFA/RBAC, monitoring, SDLC, and incident response. Summary: Trust and Security.

#### Are you responsible for Certificate Authority or trust-program decisions?

Certificate Authorities and trust programs such as AATL and EUTL make independent issuance, revocation, and inclusion decisions. Trusted Signatures does not control those decisions; our Terms clarify risk allocation and no refunds/credits for third-party trust-program actions. See Terms.

#### How do we report a security issue?

Email privacy@trusted-signatures.com with steps to reproduce. Legal notices: michelle@trusted-signatures.com and brad@trusted-signatures.com. Our security posture and responsible disclosure notes are in Trust and Security.

#### What formats do you support?

PDF today. XML/JSON and other formats are on our roadmap. Contact us if you have questions about future services.

## Already Decided to Seal PDFs? Choose the Right Implementation Path.

Canonical URL: https://trusted-signatures.com/build-vs-buy-pdf-sealing/
Source Path: content/build-vs-buy-pdf-sealing.md

Summary: A pragmatic guide for teams comparing build, buy, and hybrid implementation paths for trusted PDF sealing across engineering, security, legal, and budget concerns.

### Highlights

- Build vs buy vs hybrid
- Engineering + legal + budget tradeoffs
- Self-serve or assisted next step
- Teams who reach this page are usually past the question of whether they need PDF sealing. The real question is how to implement it without creating the wrong operational burden, trust gap, or budget shape for the workflow they are trying to protect.
- That choice is rarely only technical. It touches engineering effort, certificate and verification behavior, recipient experience in Acrobat/Reader, document residency, rollout speed, and how much ongoing trust infrastructure your team actually wants to own.
- The right answer depends on your constraints. Some teams really should build more themselves. Others should buy a managed path quickly and avoid owning more PKI and PDF-verification behavior than they need. A third group should start managed, prove workflow value, and add deeper control later.
- Treating “digitally signed PDF” and “e-signature workflow” as the same problem. They overlap sometimes, but they are not the same product decision.
- Underestimating certificate issuance, timestamping, revocation data, and viewer trust behavior. Those details are where many in-house efforts get more expensive than expected.
- Optimizing for backend elegance while ignoring the recipient experience. If recipients do not understand the result in Acrobat/Reader, the control loses value.
- Overbuilding before proving workflow value. A six-month architecture effort is often the wrong first move for a workflow that needs evidence quickly.
- Choosing a vendor model that forces full-document uploads when your policy or risk posture does not allow it.
- already know they need trusted PDF sealing
- want a fast self-serve technical proof
- care about reader-native verification behavior
- do not want to upload PDFs to a vendor if that can be avoided
- may start with a simple managed path, then add cloud-controlled deployment patterns later

### FAQs

#### When should we build vs buy PDF sealing?

Build more yourself when document trust is strategic enough to justify owning the infrastructure and long-term maintenance burden. Buy when you need a working, reader-verifiable result faster and do not want PKI, timestamp, revocation, and verification behavior to become another platform responsibility.

#### Do we need our own certificate?

Not always. Some teams need organization-specific identity or policy-specific trust paths, while others first need to prove the workflow and recipient experience. Start with the trust outcome you need, then decide how much certificate ownership is actually required.

#### Do we need AATL immediately?

Usually not on day one. Many teams should first validate the workflow, the verification experience, and the internal business case before moving into a more specific trust-path decision. When trust-path requirements are already clear, that should be part of the rollout conversation early.

#### Is this the same as e-signature?

No. PDF sealing focuses on document integrity, provenance, and tamper evidence. E-signature platforms focus on signer routing, approvals, and ceremony. Some workflows need both, but they are not interchangeable decisions.

## PDF Signing API

Canonical URL: https://trusted-signatures.com/docs/api/
Source Path: content/docs/api.md

Summary: Quickstart-first API guide for Adobe-trusted PDF sealing with HMAC authentication and CMS/PKCS 7 responses.

### Highlights

- SHA-256 digest
- CMS response
- This path is for teams integrating Trusted Signatures directly into existing PDF generation systems.
- Method: POST
- URL: https://api.trusted-signatures.com/v1/sign
- Content-Type: application/json
- X-Authorization-Algorithm: HmacSHA256
- X-Authorization-Time: current UTC ISO-8601
- X-Authorization-Key: your API key ID
- X-Authorization: base64 HMAC over raw_body + X-Authorization-Time
- signature is the CMS/PKCS 7 payload to embed into your PDF /Contents placeholder.
- Build a PDF signature placeholder (recommended ~34 KB).

## Trusted Signatures Publisher CLI

Canonical URL: https://trusted-signatures.com/docs/cli/
Source Path: content/docs/cli.md

Summary: Quickstart-first CLI guide for sealing PDFs with Adobe-trusted signatures from CI/CD and scripts.

### Highlights

- Cross-platform binaries
- Digest-only network call
- Pipeline-friendly
- Use the CLI when your team wants the fastest path from PDF generation to Acrobat-verifiable trust.
- signed.pdf opens in Acrobat/Reader with trusted signature metadata.
- Any unauthorized edits are flagged as invalid.
- --ltv: embed long-term validation data
- --tsa: embed trusted timestamp
- --limit-changes: enforce post-seal change policy
- --endpoint: override API endpoint
- Only SHA-256 digest is sent to Trusted Signatures API.
- Private document contents and metadata stay local.

## Web sealing

Canonical URL: https://trusted-signatures.com/docs/web-sealing/
Source Path: content/docs/web-sealing.md

Summary: Seal PDFs directly in your browser without uploading documents to Trusted Signatures servers. Use a test certificate, the Trusted Signatures certificate, or your organization certificate based on your subscription.

### Highlights

- No document upload
- Browser-based local sealing
- Test, Publisher, and Identity modes
- Web sealing runs in the browser so the source PDF never leaves the local device. Trusted Signatures receives only the signing material needed to produce the seal, not the document itself.
- Web sealing lets you seal PDFs directly in the browser and download the sealed result without uploading the document to Trusted Signatures servers. The PDF stays on the local device throughout the process.
- If you do not have a subscription yet, you can still test Web sealing with a test certificate.
- Your PDF is sealed locally in the browser.
- The document is not uploaded to Trusted Signatures servers.
- The sealed PDF is useful for workflow testing, but it is not Adobe-verifiable.
- Acrobat will not show the blue seal for test-mode output.
- Web sealing uses the same Publisher usage pricing as CLI and API sealing.
- One Publisher subscription supports Web sealing, CLI, API, Cloud Connector, and Zapier usage.
- If you add Publisher Identity, you can choose your organization certificate in the same browser-based flow.
- You do not need a separate browser-only subscription.

## PDF Signing With Zapier

Canonical URL: https://trusted-signatures.com/docs/zap/
Source Path: content/docs/zap.md

Summary: Automate PDF digital signing with Zapier integration. No-code workflows for Google Drive, Dropbox, forms. Get Adobe Acrobat blue seal.

### Highlights

- Sign PDFs without code using our Zapier integration and get the Adobe Acrobat blue seal.
- What You Can Do
- Prerequisites
- Step-by-Step Setup
- Field Reference
- Common Use Cases
- Testing & Troubleshooting
- Sign PDFs from Google Drive, Dropbox, OneDrive
- Trigger signing when e.g., a form submits, or spreadsheet updates
- Send signed PDFs via email, Slack, or cloud storage
- Get Adobe Acrobat blue seal verification for compliance
- Zapier account (free or paid)

## Cloud Connector Docs

Canonical URL: https://trusted-signatures.com/docs/cloud-connector/
Source Path: content/docs/cloud-connector/_index.md

Summary: Deployment and integration guides for customer-managed cloud connectors that keep PDF handling inside your infrastructure.

### Highlights

- Customer cloud boundary
- Connector deployment guides
- No external PDF transfer
- Cloud connector deployments are built for teams that want customer-managed runtimes, cloud-native controls, and the same trusted PDF outcome across AWS, Azure, GCP, and Kubernetes deployment patterns.
- Cloud Connector documentation covers deployment patterns where orchestration runs in your cloud while Trusted Signatures continues to provide managed sealing.
- AWS Cloud Connector overview
- Deployment guide
- API reference
- Secrets Manager setup
- Cloud Connector for Azure overview

## Cloud Connector for Azure

Canonical URL: https://trusted-signatures.com/docs/cloud-connector/azure/
Source Path: content/docs/cloud-connector/azure/_index.md

Summary: Deploy the Trusted Signatures Azure Function in your own Azure subscription for direct PDF sealing, Blob Storage workflows, and Power Automate integration.

### Highlights

- Azure Function deployment
- Direct and Blob Storage modes
- Power Automate compatible
- The documented Azure pattern combines Azure Functions, direct and Blob Storage modes, and Microsoft-native security controls so teams can support application and Power Automate workflows inside their own subscription.
- Use these guides to deploy and operate Cloud Connector for Azure inside your own Azure subscription.
- Deployment guide: provision Azure resources, publish the Function, and validate the sealing workflow.
- API reference: direct mode, Blob Storage mode, request shape, and returned output.
- Security guide: Key Vault, network restrictions, authentication, and monitoring controls.
- Power Automate guide: connect the Azure deployment to Power Automate for workflow-based sealing.
- Deploy the connector as an Azure Function in your own subscription.

## Cloud Connector for Azure Deployment Guide

Canonical URL: https://trusted-signatures.com/docs/cloud-connector/azure/deployment/
Source Path: content/docs/cloud-connector/azure/customer-deployment.md

Summary: Deploy the Trusted Signatures Azure Function in your own subscription for direct PDF requests or Blob Storage-based sealing workflows.

### Highlights

- Azure Function deployment
- Direct and storage modes
- Customer subscription boundary
- This document walks you through deploying the Trusted Signatures sealing Function to your own Azure subscription. It assumes general development experience but minimal Azure knowledge.
- This is the guide for deploying Cloud Connector for Azure.
- The connector provides businesses with a scalable, cost-effective API in their own infrastructure to seal even the most sensitive documents. By deploying the connector in their own Azure subscription, customers have assurance that none of the information in the documents can be intercepted or modified.
- Cloud Connector for Azure is deployed as an Azure Function. Customers can either send PDFs directly in HTTP requests (up to 50MB) or use Azure Blob Storage for larger files, invoke the Function, and receive the sealed PDF back.
- graph TB subgraph"Customer Azure Subscription"Client["Client Application"] PowerAutomate["Power Automate"] BlobSource["Blob Storage (Source)"] BlobDest["Blob Storage (Destination)"] Function["PDF Sealer Function"] Storage["Function Storage"] end
- TrustedAPI["Trusted Signatures API api.trusted-signatures.com"]
- sequenceDiagram participant Client participant Function as PDF Sealer Function participant TrustedAPI as Trusted Signatures API
- Client- Function: 1. HTTP POST (PDF + API credentials) Function- TrustedAPI: 2. HTTPS POST (PDF digest + credentials) TrustedAPI-- Function: 3. HTTPS 200 (signature data) Function-- Client: 4. HTTP 200 (sealed PDF binary)
- sequenceDiagram participant Client participant BlobSource as Source Container participant Function as PDF Sealer Function participant TrustedAPI as Trusted Signatures API participant BlobDest as Destination Container
- Client- BlobSource: 1. Upload PDF Client- Function: 2. HTTP POST (container/blob + API credentials) Function- BlobSource: 3. Download PDF Function- TrustedAPI: 4. HTTPS POST (PDF digest + credentials) TrustedAPI-- Function: 5. HTTPS 200 (signature data) Function- BlobDest: 6. Upload sealed PDF Function-- Client: 7. HTTP 200 (container/blob location) Client- BlobDest: 8. Download sealed PDF
- Azure Subscription access with rights to create resource groups, Storage Accounts, and Function Apps.

## Power Automate Guide for Cloud Connector for Azure

Canonical URL: https://trusted-signatures.com/docs/cloud-connector/azure/power-automate/
Source Path: content/docs/cloud-connector/azure/azure-trusted-signatures-gateway-guide.md

Summary: End-to-end Power Automate setup for Cloud Connector for Azure, including account setup, Azure deployment, custom connector configuration, and OneDrive workflow sealing.

### Highlights

- Power Automate custom connector
- OneDrive workflow example
- PDF stays in Azure
- This walkthrough assumes you are a new Trusted Signatures customer who wants to seal PDFs automatically. You will create a Trusted Signatures account, deploy Cloud Connector for Azure (the Azure Function provided in this repo), and build a Power Automate flow that seals OneDrive documents and stores the sealed versions in another folder.
- flowchart LR A["Power Automate Flow (collects PDF)"] B["Azure Trusted Signatures Gateway (customer Azure)"] C["Trusted Signatures API (Trusted Signatures infra)"]
- Power Automate Flow: Collects the PDF (e.g., from OneDrive) and sends it to the gateway running inside _your_ Azure tenant.
- Azure Trusted Signatures Gateway: Executes the sealing logic locally. The raw PDF never leaves your Azure infrastructure. The gateway computes the required digest and assembles the sealing request.
- Trusted Signatures API: Only receives the SHA digest needed to apply the signature. No PHI/PII, metadata or document content traverses Trusted Signatures infrastructure.
- Sensitive content remains inside your Azure environment, under your compliance boundary.
- Trusted Signatures only processes the cryptographic digest and cannot reconstruct the original document or any metadata.
- This architecture satisfies scenarios where regulations prevent sharing full documents externally while still leveraging Trusted Signatures sealing service.
- Visit https://secure.trusted-signatures.com and sign up for an account.
- After verifying your email and signing in, navigate to API Keys ➜ Create Test Key.
- Note the API Key ID and the API Key (hex string). You will need both for the gateway.

## Publisher - Trusted PDF Sealing

Canonical URL: https://trusted-signatures.com/product/publisher/
Source Path: content/product/publisher.md

Summary: Seal PDFs in place with API, CLI, Web sealing, Zapier, Cloud Connector, or Power Automate so recipients see trusted, tamper-evident status in Acrobat/Reader.

### Highlights

- Adobe/Acrobat trust signal
- PAdES + LTV support
- Managed HSM custody
- Publisher adds tamper-evident trust to PDFs you already generate. Use API, CLI, Web sealing, Zapier, Cloud Connector, or Power Automate from your existing systems, keep documents in your environment, and let recipients verify trust directly in Acrobat/Reader.
- Use Web sealing when you want to seal PDFs directly in the browser without uploading documents to Trusted Signatures. Test users can seal with a test certificate that does not produce an Acrobat blue seal. Publisher subscribers can seal with the Trusted Signatures certificate, and Publisher Identity subscribers can seal with their organization certificate so Acrobat shows their company as the sealer.
- For implementation details, start with our API docs, CLI docs, Web sealing guide, Zapier docs, or the cloud connector product pages.
- Fewer document authenticity disputes and callback loops.
- Faster approval decisions because trust status is visible on open.
- Exception-based review for altered documents instead of manual spot checks.
- Portable evidence aligned to widely used PDF and PKI standards.
- export TS_API_KEY_ID=""export TS_API_KEY=""sign-pdf --input input.pdf --output signed.pdf --apikeyid"$TS_API_KEY_ID"--apikey"$TS_API_KEY"
- Publisher seals follow ISO 32000/PDF signature structures and standard X.509 chain validation behavior. Optional RFC 3161 timestamping and OCSP/CRL embedding support long-term validation requirements in Adobe workflows.
- This allows trust verification to stay with the document. Recipients can validate origin and integrity in Acrobat/Reader without relying on a separate portal or proprietary viewer. On-screen trust banners depend on the viewer trust store and local configuration.
- Need your organization to appear as the signer? Add Publisher Identity for AATL or EU Advanced trust paths.
- Deploy Publisher connectors into your Azure, AWS, Google Cloud, or Kubernetes environment. Orchestration runs in your cloud; sealing still happens in Trusted Signatures’ secure service. Ideal for teams already managing cloud networks and automation flows.
- Runs in your own cloud accounts/tenants

### FAQs

#### Is this an e-signature workflow tool?

No. Publisher seals PDFs and proves integrity/origin; it is not a routing workflow for signer approvals.

#### Will recipients need to install anything?

No. Validation is reader-native in Adobe Acrobat/Reader and other compatible PAdES viewers.

#### What does Acrobat/Reader show after sealing?

In compatible trust configurations, recipients can see certified trust indicators and signer details. Unauthorized edits are flagged when validation fails.

#### Can recipients fill forms or add comments without breaking the seal?

Yes. DocMDP policies can allow form fill and annotations while still blocking unauthorized content edits.

#### Will sealed PDFs validate in Adobe Acrobat/Reader and downstream systems (PAdES + LTV)?

Yes. Publisher supports ISO 32000 signatures with X.509 chain data and optional RFC 3161 + OCSP/CRL embedding for long-term validation.

#### Do we have to upload files to Trusted Signatures to seal them?

No. Files stay in your environment. Publisher works in place through API, CLI, Web sealing, Zapier, Cloud Connector, or Power Automate automation.

#### How can we preview what sealed vs. unsealed looks like before buying?

Use the free PDF Validator to compare trust and integrity signals before rollout.

#### How is pricing structured for Publisher and Identity?

Publisher is a usage-based subscription. Publisher Identity (AATL or EU Advanced OrgID) is an annual add-on.

#### Where are the signing keys kept?

Keys are non-exportable and held in FIPS 140-3 Level 3 HSMs; signing operations occur inside the module.

#### Can we bring our own certificate? How do we show our organization as the signer?

BYO certificates are not supported. To display your organization as signer in Acrobat, add Publisher Identity.

## Publisher for Cloud Platforms

Canonical URL: https://trusted-signatures.com/product/publisher-cloud/
Source Path: content/product/publisher-cloud.md

Summary: Run high-volume Publisher orchestration in your own cloud with function or Kubernetes deployments while sealing stays in Trusted Signatures' secure service.

### Highlights

- Runs in your cloud boundary
- Function or Kubernetes deployment
- Built for enterprise volume
- Publisher Cloud gives enterprise teams the same standards-based PDF sealing capability as Publisher, but with orchestration deployed inside your own cloud environment. Use functions or Kubernetes-based services to handle high-volume document flows while keeping your networking, observability, and automation inside your platform boundary.
- Keep document-sealing orchestration inside your own cloud governance boundary.
- Support higher-volume PDF generation and sealing pipelines without changing recipient validation behavior.
- Reuse your existing logging, monitoring, queueing, and secret-management controls.
- Give platform teams one internal service pattern for many document-producing applications.
- Publisher Cloud preserves the same ISO 32000/PDF signature structures and X.509-based validation behavior as Publisher. Optional timestamping and long-term validation evidence can still be part of the sealing workflow, while your orchestration layer stays under your cloud operations model.
- Recipients do not need a custom viewer or plugin. Trust verification remains document-native in Acrobat/Reader and other compatible PAdES viewers, subject to reader trust-store configuration.
- Publisher Cloud is positioned for enterprise deployments that want a predictable platform model for running the orchestration layer in their own environment. Final planning depends on deployment shape, expected volume, and whether you pair it with Publisher Identity.
- Best fit for teams with established cloud or Kubernetes operations.
- Supports single-region, multi-region, and multi-cluster rollout planning.
- Works alongside standard Publisher and Publisher Identity services when needed.

### FAQs

#### What runs in our cloud versus Trusted Signatures?

Your orchestration component runs in your cloud account or cluster. Trusted Signatures still performs the managed sealing operation in its secure service.

#### Do PDFs have to leave our environment?

No. The deployment pattern is designed so your cloud-hosted service can keep PDFs local and exchange only the sealing request data required for the signing operation.

#### Which platforms are supported?

Teams typically deploy with cloud functions, container services, or Kubernetes in Azure, AWS, Google Cloud, and similar enterprise environments.

#### When should we choose Publisher Cloud over the standard Publisher workflows?

Choose Publisher Cloud when you need orchestration inside your own cloud boundary, have platform teams already operating cloud workloads, or need a deployment model suited for higher-volume document flows.

#### How is pricing structured?

Publisher Cloud is positioned for enterprise deployments with subscription-based platform access, alongside sealing usage planning based on expected document volume.

#### How do credentials and secrets work?

Use your cloud's native secret-management controls to hold API credentials and restrict access to the service that submits sealing requests.

## Cloud Connector for Power Automate

Canonical URL: https://trusted-signatures.com/product/power-automate-connector/
Source Path: content/product/power-automate-connector.md

Summary: Run sealing actions from Power Automate while PDFs stay inside your Azure cloud through your Cloud Connector for Azure deployment.

### Highlights

- Power Automate workflow action
- Requires Cloud Connector for Azure
- PDF stays in your cloud
- Cloud Connector for Power Automate lets teams trigger sealing directly from Microsoft Power Automate while keeping PDF handling inside their own Azure deployment. A flow sends the PDF, credentials, and sealing options to the customer's Cloud Connector for Azure, which performs the sealing operation without moving the file outside the customer's cloud.
- Give Power Automate users a native sealing step without pushing PDFs outside the customer's cloud.
- Reuse your Cloud Connector for Azure deployment across many document workflows.
- Reduce custom integration work for teams already committed to Microsoft workflow tooling.
- Keep recipient validation behavior unchanged in Acrobat and other compatible PAdES viewers.
- Cloud Connector for Power Automate preserves the same standards-based PDF sealing behavior as Publisher and Cloud Connector for Azure. The workflow path changes how teams invoke sealing, not how recipients verify the document.
- That means the returned PDF still follows the same ISO 32000 and X.509 trust model, with Acrobat/Reader and other compatible PAdES viewers used for recipient validation.
- Cloud Connector for Power Automate is positioned for teams that want Power Automate workflow integration on top of their Cloud Connector for Azure deployment.
- Best fit for Microsoft-centric workflow environments.
- Planned together with your Azure connector footprint and expected flow volume.
- Works alongside standard Publisher and Publisher Identity services where needed.

### FAQs

#### Is Cloud Connector for Azure required?

Yes. Cloud Connector for Power Automate is designed for customers already running the Cloud Connector for Azure inside their own environment.

#### Does the PDF leave our Azure environment?

No. The Power Automate action sends the PDF and parameters to your Cloud Connector for Azure, so the document remains inside your cloud boundary.

#### What does the flow pass into the connector?

Flows typically send the PDF payload plus API key material or references, certificate selection details, and sealing parameters required by your Azure deployment.

#### What comes back to the flow?

The action returns the sealed PDF and related response metadata so later steps can store, email, or route the trusted document.

#### When should we use this instead of direct API integration?

Use it when business or operations teams already automate document handling in Power Automate and want sealing available as a native workflow step.

#### How is pricing structured?

Cloud Connector for Power Automate is planned alongside your Cloud Connector for Azure deployment and expected workflow volume.

## PDF Validator - Trust Made Visible

Canonical URL: https://trusted-signatures.com/product/pdf-validator/
Source Path: content/product/pdf-validator.md

Summary: Drop a PDF to check who signed it, whether it’s been changed, and when. Runs in your browser; no uploads required. Works with any standards-based signed PDF.

### Highlights

- Standards-based PDF verification
- No file upload required
- Works with Acrobat trust model
- Use the Validator when you need a fast answer to three questions: is this PDF signed, has it changed, and does the certificate chain look trustworthy? The check runs in the browser and works with standards-based PDF signatures, not just files sealed by Trusted Signatures.
- Best use case: verify a received PDF before you rely on it for payment, compliance, or approval.
- What it checks: signature integrity, certificate trust status, and timestamp evidence.
- What it does not require: account setup, file upload, or a Trusted Signatures-issued seal.
- In our Validator, Adobe Acrobat/Reader and any PAdES-compliant reader, recipients see a blue “Certified” banner for authentic, unchanged files.
- It checks the same standards signals Acrobat/Reader use for signed PDFs (ISO 32000/PDF; PAdES behaviors). Results may vary based on local trust stores
- Yes. It validates any standards-based PDF signature, including those not sealed by Trusted Signatures.
- Yes, our web Validator is free. If you are interested in automating validation checks in your workflows using CLI, API, Web sealing, Zapier, or Documenso integrations, contact us to learn more about our Validator roadmap.
- We designed Publisher - Trusted PDF Sealing to remove the barriers most organizations have to securing documents: the expense and complication of managing certificates (organizational verifications), PKI management and security. This is the most affordable, easiest to implement solution on the market. Add Publisher Identity and your organization’s name appears in the Certified banner so your recipients can trust what you send them came from you, unaltered.

### FAQs

#### Is this the same as Adobe Acrobat validation?

It checks the same standards signals Acrobat/Reader use for signed PDFs (ISO 32000/PDF; PAdES behaviors). Results may vary based on local trust stores

#### Does the Validator work with non-Trusted Signatures seals?

Yes. It validates any standards-based PDF signature, including those not sealed by Trusted Signatures.

#### Is it free?

Yes, our web Validator is free. If you are interested in automating validation checks in your workflows using CLI, API, Web sealing, Zapier, or Documenso integrations, contact us to learn more about our Validator roadmap.

#### My critical documents show no signature. How can I secure my documents so I can quickly see fakes or fraud attempts?

We designed Publisher - Trusted PDF Sealing to remove the barriers most organizations have to securing documents: the expense and complication of managing certificates (organizational verifications), PKI management and security. This is the most affordable, easiest to implement solution on the market. Add Publisher Identity and your organization’s name appears in the Certified banner so your recipients can trust what you send them came from you, unaltered.

## Publisher Identity

Canonical URL: https://trusted-signatures.com/product/identity/
Source Path: content/product/identity.md

Summary: Show your verified organization as signer in Acrobat/Reader with managed AATL or EU Advanced OrgID lifecycle.

### Highlights

- AATL or EU Advanced trust paths
- Managed CA/RA validation
- Lifecycle and revocation support
- Publisher Identity adds organization-level signer identity to your existing Publisher sealing workflow. Keep the same API, CLI, Web sealing, Zapier, Cloud Connector, or Power Automate process while we manage validation, certificate issuance, renewals, and revocation coordination.
- If you already use Publisher, Publisher Identity lets the same Web sealing flow show your organization as the signer in Acrobat instead of Trusted Signatures. The PDF is sealed locally in the browser and is never uploaded to Trusted Signatures servers.
- Identity issues and manages organization-level X.509 certificates that align to AATL or EU Advanced trust-path expectations while preserving the same standards-based sealing behavior (ISO 32000/PAdES profile patterns) in Publisher.
- When recipients open sealed PDFs, validation remains reader-native: signer identity, integrity status, and related trust metadata are available in Acrobat/Reader. On-screen trust banners depend on viewer trust-store and local configuration.
- For browser-based flows, Identity follows the same local-document model as Web sealing: the PDF stays in the user's browser, Trusted Signatures never receives the document itself, and the selected organization certificate determines the signer shown in Acrobat.
- Publisher Identity is an annual add-on to Publisher sealing. Path selection (AATL or EU Advanced) and organization validation scope determine issuance timelines and planning.
- Requires an active Publisher sealing service.
- Available for teams with one or multiple organization certificates.
- Includes lifecycle support for renewals and revocation events.
- Uses the same Publisher subscription across Web sealing, CLI, API, Cloud Connector, and Zapier paths.
- AATL targets broad Adobe ecosystem trust globally. EU Advanced targets workflows that reference eIDAS/EUTL policy expectations.

### FAQs

#### What’s the difference between AATL and EU Advanced OrgIDs?

AATL targets broad Adobe ecosystem trust globally. EU Advanced targets workflows that reference eIDAS/EUTL policy expectations.

#### Do I need Publisher Identity if I already use Publisher sealing?

No. Publisher sealing works by itself. Add Identity when you need your organization shown as signer.

#### How long does OrgID validation usually take?

Validation timelines vary by CA/RA requirements, trust-path selection, and documentation readiness.

#### Can we bring our own certificate?

No. We manage issuance and key custody for lifecycle and security consistency.

#### Can we switch trust paths later?

Yes. Switching requires new certificate issuance; we coordinate transition timing.

#### What happens if a certificate is revoked or expires?

We manage renewal and revocation handling. With LTV enabled, earlier sealed files remain verifiable based on signing-time evidence.

## Data Processing Addendum (DPA)

Canonical URL: https://trusted-signatures.com/docs/dpa/
Source Path: content/docs/dpa.md

Summary: Trusted Signatures DPA: controller/processor roles, security measures, subprocessors, international transfers, and HIPAA operations-only scope.

### Highlights

- Effective Date: 11/30/2025 Last Updated: 10/31/2025
- Trusted Signatures (“TS,” “we,” “our”) and the counterparty identified in the applicable order form (“Customer”) agree to this Data Processing Addendum (DPA), which forms part of the agreement governing Customer’s use of the Services. Capitalized terms not defined here have the meanings in the Agreement or applicable law.
- Controller vs. processor. (a) For Account, Billing, Support, and Site data, TS acts as controller/business (see our Privacy Policy). (b) For Customer-submitted technical data processed to operate the Services (e.g., API logs, SHA-256 document digests, certificate serials/issuer, validation outcomes), TS acts as processor/service provider on Customer’s documented instructions.
- TS will process Customer Personal Data only: (a) to provide, secure, and support the Services; (b) per Customer’s written instructions (including the Agreement and this DPA); or (c) as required by law (with notice to Customer unless prohibited).
- Subject matter & duration. Processing of Customer Personal Data for the term of the Agreement and the retention windows in §8. Nature & purpose. Operating PDF sealing/verification workflows; security, support, and billing. Categories & subjects. As provided by Customer (e.g., account contacts, API users; document-verification metadata). Data subjects may include Customer’s personnel, end users, and vendors.
- TS maintains appropriate technical and organizational measures, including: encryption in transit and at rest (where applicable); SSO/MFA; role-based access and least privilege; audit logging and monitoring (AWS CloudWatch); vulnerability management; secure SDLC; incident response; and HSM-backed key protection using FIPS 140-validated modules (Level 3 where applicable). See Annex II (Security Measures).
- TS will ensure personnel accessing Customer Personal Data are bound by confidentiality and receive appropriate privacy/security training. Access is limited to a need-to-know basis.
- Authorization & flow-down. Customer authorizes TS to use Subprocessors to provide the Services. TS will impose data-protection obligations no less protective than those in this DPA and remains responsible to Customer for each Subprocessor’s performance of those flow-down obligations (subject to the limitations in the Agreement).
- Current list & notice. TS maintains a live list at: Subprocessors List. TS may update Subprocessors by updating that page (which constitutes notice). Customers may object to a new Subprocessor under the process in Annex I §D.
- TS will provide reasonable assistance, proportionate to its role, with security-related obligations, DPIAs, consultations with authorities, and data-subject requests that Customer receives and directs to TS.
- At termination or upon Customer request, TS will delete or return Customer Personal Data, unless retention is required for legal, security, audit, or trust-program reasons; in that case, TS will protect the data per this DPA and delete on the next standard cycle. Typical retention windows are described in the Privacy Policy.
- TS will notify Customer without undue delay after becoming aware of a Personal Data Breach involving Customer Personal Data and will provide information reasonably available to assist Customer with legal notification duties and remediation.
- Where Customer Personal Data is transferred to TS in the U.S. or another third country, the parties incorporate the appropriate Standard Contractual Clauses (EU 2021/914 C2P) and, as applicable, the UK IDTA/UK Addendum and Swiss addenda. If there is conflict, the SCCs/addenda control for the transfer.
- TS will not: (a) sell Customer Personal Data; (b) share it for cross-context behavioral advertising; (c) process it outside the business purpose of providing the Services; or (d) combine it with personal information from other sources except as permitted for security, fraud prevention, or service operations.
- The Services are not designed to receive or store PHI. Customer must not send PHI in document content, filenames, content-derived metadata, or support materials. If required, TS may execute a HIPAA Business Associate Rider (Operations-Only) that covers Operational Metadata (e.g., API logs, SHA-256 digests, certificate/validation status data) and expressly excludes document content. See our HIPAA Rider.
- Upon written request (no more than annually or following a material incident), TS will make available summary reports or attestations relevant to these controls (e.g., penetration test summaries). Where additional verification is needed, the parties will agree in advance on scope, timing, confidentiality, and reasonable cost recovery.
- The Agreement’s limitations and exclusions of liability (including ToS §15) apply to this DPA. If there is a conflict between this DPA and the Agreement, this DPA controls to the extent required by law; otherwise, the Agreement controls. For transfer conflicts, §10 controls.
- A. Exporter (Controller/Business). Customer (entity named in the order form). B. Importer (Processor/Service Provider). Trusted Signatures, 4 Saint Albans Rd W, Hopkins, MN 55305. C. Data subjects. Customer employees/contractors; Customer’s vendors/end users. D. Categories of data. Account/contact data; API/service logs (timestamps, IPs, user/tenant IDs, endpoint, status/latency); document-verification metadata (SHA-256 digests, certificate serials/issuer, validation outcomes); identity data provided for Publisher Identity onboarding (org details, authorized contacts, proofs). E. Special categories. Not intended. Customer will not submit sensitive data unless required and lawfully justified. F. Subprocessor notice & objections. TS will post updates at /docs/subprocessors. Within 15 days of an update, Customer may reasonably object on data-protection grounds. If unresolved in good faith, Customer may suspend the affected functionality or terminate the impacted order(s) with a pro-rata refund of prepaid, unused fees.

## TS Subprocessors List

Canonical URL: https://trusted-signatures.com/docs/subprocessors/
Source Path: content/docs/subprocessors.md

Summary: Trusted Signatures subprocessors: Stripe, AWS, Sectigo, and more. See data categories, regions, safeguards, and change log. GDPR/DPA aligned; U.S. hosting.

### Highlights

- Effective Date: 10/31/2025
- Last Updated: 10/31/2025
- This page identifies the third-party Subprocessors that Trusted Signatures (“TS”) uses to deliver the Services. Subprocessors process limited personal information on TS’s behalf and are bound by data-protection and confidentiality terms. TS remains responsible to you for each Subprocessor’s performance of the data-protection obligations we flow down to them under our DPA (subject to the limitations in our Terms). Certain providers may also act as independent controllers for their own purposes (e.g., payment processing fraud/chargebacks) or make independent trust-program decisions (e.g., CA issuance/revocation); TS is not responsible for those independent activities.
- Provider: Stripe, Inc.
- Purpose: Payment card processing, fraud prevention, disputes/chargebacks.
- Data processed: Billing contact data and transaction metadata; no full card numbers or CVV are stored by TS.
- Processing location: U.S. and global infrastructure.
- Safeguards: PCI DSS; SCCs/UK Addendum as applicable.
- Policies: See Stripe’s privacy/terms.
- EU Advanced Provider: Sectigo Limited and affiliates (CA/RA, OCSP/CRL, and RFC 3161 Time-Stamping Authority)
- Purpose: Organization certificate issuance, validation/revalidation, suspension/revocation; certificate status checks; trusted timestamps.
- Data processed: Organization identity data (as provided by Customer for validation), certificate serials/issuer, request/response metadata.
- Processing location: EU/UK/US (varies by service).
- Safeguards: Sectigo CPS/Subscriber terms; SCCs/UK Addendum as applicable.

## Privacy Policy

Canonical URL: https://trusted-signatures.com/privacy/
Source Path: content/privacy.md

Summary: Trusted Signatures privacy policy. Learn how we protect your data, what we collect, and your privacy rights.

### Highlights

- Effective Date: 11/30/2025 Last Updated: 10/31/2025
- Change summary (10/31/2025): We clarified roles (controller vs. processor), named core providers (Stripe, AWS, Sectigo, AWS CloudWatch), added retention windows, and included U.S. state privacy rights. See the announcement for details.
- Trusted Signatures (“Trusted Signatures,” “TS,” “we,” “our,” or “us”) is committed to protecting your privacy. This Privacy Policy explains how we collect, use, disclose, and protect personal information in connection with our Services. Capitalized terms not defined here have the meanings given in our Terms of Service.
- Scope. This Policy covers personal information we process when you visit our websites, create an account, use the Services, or interact with us. Roles.
- For account, billing, support, marketing, and site analytics, TS is a data controller (a “business” under U.S. state privacy laws).
- For customer-submitted content and metadata processed to seal/verify PDFs (e.g., document digests), TS acts as a data processor/service provider on your instructions, per our Terms and any data processing addendum (DPA).
- For payment processing, TS is the billing controller (merchant of record) deciding who is billed, for what, and when; Stripe processes payment card data on our behalf. Stripe may also act as an independent controller for its own purposes (e.g., fraud, disputes/chargebacks, and regulatory compliance).
- (a) Account & billing. Name, email address, organization name, billing contacts, subscription details, transaction metadata. We do not collect or store full payment card numbers or CVV; these are collected and processed by our payment provider (Stripe). We may receive limited payment metadata (e.g., last four digits, card type, expiration month/year, tokens, transaction outcomes).
- (b) Service & API usage. We log API requests for auditing, security, and usage tracking. This may include your IP address, timestamps, API key identifiers, PDF digest, and requested operations.
- (c) Document metadata (no PDFs). Where required, we process and may retain non-content metadata such as SHA-256 digests, timestamps, certificate serial numbers/issuer, validation outcomes, and signer identity fields you instruct us to apply—strictly for verification, audit, and fraud-prevention purposes. We never upload or store your PDF documents.
- (d) Identity products (Publisher Identity). For AATL OrgID and EU Advanced OrgID onboarding and lifecycle, we may collect organization identity data you provide (e.g., business name, addresses, registration numbers, authorized contacts, and proof documents) to coordinate with Certificate Authorities (CAs) and Registration Authorities (RAs).
- (e) Support & communications. Messages, tickets, diagnostics, and related metadata.
- (f) Website & device data. Cookies and similar technologies for essential operations, security, and analytics (see §8).
- We use information to: (a) provide, secure, and operate the Services (contract/legitimate interests); (b) authenticate and manage accounts, keys, and entitlements (contract/legitimate interests); (c) prevent abuse, fraud, and security incidents; investigate errors (legitimate interests/legal obligations); (d) issue and manage organization certificates for Identity products with CAs/RAs/TSA/OCSP/CRL services (contract/legal obligations/legitimate interests); (e) process payments and comply with tax, accounting, and regulatory requirements (legal obligations/contract); (f) provide support and communicate about updates, billing, and policy changes (contract/legal obligations); (g) improve the Services and develop features (legitimate interests); and (h) send optional product and event communications (consent where required; you may opt out).
- We do not sell or rent personal information. We disclose limited information as follows: (a) Service providers/subprocessors. Cloud hosting, security/monitoring, analytics, support, and payment processing—bound by confidentiality and data-protection terms. (b) Payments (Stripe). We disclose necessary billing and transaction data to Stripe to process payments, prevent fraud, and handle disputes. Stripe’s processing of payment card data is governed by its own terms and privacy notices. (c) Trust services for signing/validation. Where applicable, to CAs/RAs, time-stamping authorities (TSA), and revocation/validation services (OCSP/CRL) to issue, validate, suspend, or revoke certificates and timestamps per program rules. (d) Compliance & safety. To comply with laws, lawful requests, or to protect rights, safety, and the integrity of the Services. (e) Business transfers. In a merger, acquisition, or asset transfer, in accordance with applicable law.
- A current list of core subprocessors is available on request.
- (a) account and billing records: up to 7 years for tax/accounting/contract compliance;
- (b) security and API logs: typically 12–24 months (longer if needed for investigations, regulatory, or audit purposes);

## Terms of Service

Canonical URL: https://trusted-signatures.com/terms/
Source Path: content/terms.md

Summary: Trusted Signatures terms of service. Understand your rights and responsibilities when using our digital PDF signature API and CLI tools.

### Highlights

- Effective Date: 11/30/2025
- Last Updated: 10/31/2025
- Change summary (10/31/2025): We clarified certificate/trust-program rules (including no refunds for CA/trust-list actions), expanded customer security/legal-use responsibilities, refined termination triggers, and standardized warranty/limitation terms. See the announcement for details.
- Welcome to Trusted Signatures ("TS","we","our"). By using our services, you agree to these terms.
- Use of Trusted Signatures ("TS") service is subject to these Terms and our Privacy Policy. If you do not agree, do not use the services.
- Business use only. TS provides API- and CLI-based tools to apply PDF digital signatures/seals to documents that you process in your own environment. We do not offer legal advice, notarial services, or consumer e-signature workflows. Validation results depend on the recipient’s PDF viewer trust configuration and on PDF features such as certification signatures (DocMDP), legal attestations, and incremental updates, which can affect how changes are flagged or permitted. TS does not provide legal advice; you are responsible for determining the legal effect of any signature or seal in your jurisdictions. See §15 for warranty disclaimers and limitations. The Services are not designed to receive PHI; see §5 and §13.2.
- You must be 18+ years of age and create an account to obtain API keys. You are responsible for key confidentiality, rotation, and all activity under your account. Test keys are for evaluation and may use self-signed or test certificates; they are not appropriate for production due to lower assurance. You are responsible for credential hygiene, including (a) key rotation, (b) secure storage, and (c) immediate revocation on suspected compromise.
- Overview: Trusted Signatures (“TS”) provides tools to apply standards-based digital signatures/seals to PDF documents and, where purchased, to procure and manage organization certificates used for those seals. Validation outcomes depend on recipient trust settings and applicable standards behavior (e.g., certification signatures, DocMDP/FieldMDP permissions, legal attestations, and incremental updates).
- Applies an organizational-verification (OV) seal to PDFs designed for Adobe-compatible validation in Acrobat/Reader. Publisher can attach revocation data (OCSP/CRL) and trusted timestamps (e.g., RFC 3161) and enable long-term validation (LTV), and may set certification (DocMDP) permissions to allow or restrict post-seal changes (e.g., form-fill or additional signatures) without breaking trust.
- Scope & Limits. Publisher does not by itself confer inclusion in any third-party trust program. Validation indicators shown to recipients (e.g., “Certified by …”) are determined by the viewer’s trust store and settings. TS does not control recipient software behavior.
- Provides issuance and lifecycle management of organization-validated (OV) document signing certificates through a Certificate Authority (CA) recognized within the Adobe Approved Trust List (AATL) ecosystem, for use with Publisher sealing. Customer must complete CA/RA validation, keep organization information current, and comply with the CA’s Subscriber Agreement and CPS. Issuance, suspension, and revocation decisions are made by the CA and may affect downstream validation.
- Scope & Limits. AATL recognition depends on third-party trust-program rules and the recipient’s viewer configuration. TS does not guarantee inclusion or continued inclusion in any trust list.
- Provides issuance through a Certificate Authority (CA) and lifecycle management of organization-validated (OV) certificates recognized within EU “Advanced” trust paths (i.e., via EUTL-listed providers) for use with Publisher sealing. Customer must complete CA/RA validation, keep organization information current, and comply with the CA’s Subscriber Agreement and CPS. Issuance, suspension, and revocation decisions are made by the CA and may affect downstream validation.
- Scope & Limits. Trust recognition depends on the relevant EU trust framework and recipient configuration. Provider decisions (issuance, suspension, revocation) may impact validation; TS does not control those decisions. Qualified (QES) certificates are not available.
- TS implements industry-standard PDF signing constructs consistent with ISO 32000 (PDF) and PAdES behaviors, including approval vs. certification signatures, DocMDP/FieldMDP permission dictionaries, inclusion of OCSP/CRL revocation data and RFC 3161 timestamps where available, and support for incremental updates and LTV to the extent supported by the chosen certificate, timestamp, and recipient software.
- Third-party dependencies. Certificates, timestamps, and revocation information are provided by third parties. Availability, inclusion in trust programs (e.g., AATL, EU trust lists), and validation banners are outside TS’s control.
- Accurate identity & key stewardship (Identity products). Customer must provide accurate organization data, respond to CA/RA requests, protect credentials/keys, and request revocation if data becomes inaccurate or credentials are compromised.
- Viewer variance. Because validation depends on recipient software and trust stores, indicators and permissions enforcement (e.g., for DocMDP) may vary by viewer and configuration.

## RAG Kit - Analyst Resources

Canonical URL: https://trusted-signatures.com/rag/
Source Path: content/rag/_index.md

Summary: Machine-readable data files for AI analysis and research about Trusted Signatures products and services.

### Highlights

- This page provides machine-readable data files for AI systems, analysts, and researchers studying Trusted Signatures products and services.
- These resources are generated directly from the website source content and include source provenance for each record.
- The kit is intended to support factual grounding for FAQs, product and pricing retrieval, implementation-path selection, docs and quickstart retrieval, and trust or diligence review.
- Use excerpts for analysis, research, and AI training
- Quote facts and technical specifications with attribution
- Reference pricing and feature information
- Attribution required:"Source: Trusted Signatures (https://trusted-signatures.com)"
- AI/ML model training and fine-tuning
- Competitive analysis and market research
- Technical documentation, implementation-path selection, and integration planning