Defensible by construction.

· Hybrid signatures (Seal & Sign): ECDSA P-256 (FIPS 186-5) + ML-DSA-65 / Dilithium(FIPS 204, 2024). Both signatures cover the same byte range; verification requires both. Breaking one doesn’t break the other.

· Hybrid encryption (Vault & My Vault): X25519 ECDH + ML-KEM-768 / Kyber (FIPS 203, 2024) → HKDF-SHA-256 → AES-256-GCM. Quantum-safe even when ECDH eventually falls.

· Trusted timestamping: RFC 3161 Time-Stamp Token embedded as PAdES B-LT inside the CMS structure, with a qualified TSA chain. Replay protection comes from the TSA token plus SigningTime; we never trust client clocks. Enterprise tenants can pin their own TSA chain.

· Key handling:tenant signing keys held in a hardware security module behind a tenant-scoped key alias. Recipient secret keys are envelope-encrypted at rest, decrypted only inside the secure enclave for the duration of a single operation, and zeroed from process memory after use. Enterprise BYOK ties the key alias to the customer’s own key-management infrastructure.

PQC Shield runs end-to-end on enterprise-grade cloud infrastructure covered by independent third-party attestations across the major frameworks below. These cover the underlying platform our service depends on; auditor packets, current attestations, and our own information-security controls are available under NDA for qualifying engagements.

Beyond the PAdES signature, we emit an immutable evidence document for every successful seal. Three independent anchors that corroborate each other — together they tie hash to time without any one of them being a single point of failure:

· Anchor 1 — Cryptographic seal. Hybrid ECDSA + ML-DSA signatures embedded in the PDF, plus the RFC 3161 timestamp token in the CMS. This is the primary defence; the next two anchors are independent corroboration.

· Anchor 2 — Write-once retention. A JSON manifest containing the digest, both signatures, and the TSA token is written to write-once-read-many storage with a multi-year retention lock. Once written, neither we nor the underlying platform operator can mutate the bytes for the retention period.

· Anchor 3 — Independent platform attestation. The manifest is signed by an asymmetric ECDSA P-384 key whose public half we publish to customers and auditors on request; the signature is verifiable offline. Every signing call is captured as an independent platform audit event with timestamp, principal, key id, and request id, so the moment of issuance is corroborated by a log we cannot retroactively edit.

· Endpoint: GET /v1/seals/{sealId}/evidence returns the JSON envelope (canonical bytes + signature). Tenants can fetch their own; we hand it to opposing counsel directly on subpoena.

· Retained: SHA-256 of the original and sealed PDFs; both signatures; the TSA token; the certificate of sealing; the audit row; the evidence manifest in write-once retention.

· Not retained: the original PDF bytes. Once sealed, we stream the sealed PDF + certificate back and drop the input. We literally cannot leak the original because we never persisted it.

· Vault & My Vault ciphertexts:stored encrypted (AES-256-GCM) under recipient-bound or tenant-bound keys. Plaintext never touches our disk; decryption happens inside the recipient’s browser after the identity check passes.

Don’t take our word for any of this:

· Cryptographic verifier: /verify accepts any sealed PDF and validates both signatures + the TSA token in the browser. No account needed, free forever.

· Evidence manifest: any tenant can pull GET /v1/seals/{id}/evidence and validate the embedded asymmetric signature offline using the public key we publish on request.

· Independent compliance reports: available to your auditor under NDA for qualifying engagements. Reach us at hello@pqcshield.cloud to set up the diligence packet exchange.

Found a vulnerability? Email security@pqcshield.cloud with reproduction steps. Acknowledgement within 1 business day. Full policy in the security overview.