Encryption Standards for Document Signing: AES-256, TLS, and Beyond

Why Encryption Matters for Document Signing

Encryption in a document signing context serves two distinct purposes. Encryption in transit protects documents and signing data as they move between the signer's browser and the signing platform, and between the platform and its storage layer. Encryption at rest protects documents and audit data while stored, ensuring that a compromise of the storage layer does not expose document content.

For regulated industries, encryption is not optional — it is a baseline expectation. The NCSC, FCA, PRA, and ICO all reference encryption as a fundamental security control. But stating that a platform "uses encryption" is insufficient. Regulators and security teams need specifics: which algorithms, which key lengths, which protocols, and how keys are managed.

Encryption in Transit: TLS 1.3

Transport Layer Security (TLS) is the protocol that encrypts data as it moves across networks. TLS 1.3, published as RFC 8446 in August 2018, is the current standard and represents a significant improvement over its predecessors.

Key improvements in TLS 1.3 relevant to document signing:

• Reduced cipher suite complexity — TLS 1.3 removes support for legacy cipher suites that had known weaknesses (RC4, DES, 3DES, static RSA key exchange). Only modern, authenticated encryption with associated data (AEAD) cipher suites are permitted: AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305.
• Forward secrecy by default — all TLS 1.3 handshakes use ephemeral key exchange (Diffie-Hellman or ECDH), ensuring that compromise of the server's long-term private key does not allow decryption of past sessions. This is particularly important for document signing platforms, where historical traffic may contain sensitive documents.
• Faster handshake — TLS 1.3 completes the handshake in one round trip (compared to two in TLS 1.2), reducing latency for signers and improving the user experience.
• Encrypted handshake — the server certificate is encrypted during the TLS 1.3 handshake, preventing passive observers from identifying which service the client is connecting to based on the certificate.

For regulated platforms, the NCSC recommends TLS 1.2 as the minimum acceptable version, with TLS 1.3 as the preferred version. TLS 1.0 and 1.1 should be disabled entirely — they contain known vulnerabilities that cannot be fully mitigated.

Encryption at Rest: AES-256

The Advanced Encryption Standard (AES) with a 256-bit key is the standard for encrypting stored data. AES-256 is approved by GCHQ/NCSC for protecting information classified up to SECRET, making it more than sufficient for OFFICIAL and OFFICIAL-SENSITIVE government documents and for regulated financial services data.

In a cloud-hosted document signing platform, AES-256 at rest is typically implemented through the cloud provider's key management service. In AWS, this means:

S3 server-side encryption (SSE-KMS). Documents stored in S3 are encrypted using AES-256 with keys managed by AWS Key Management Service (KMS). Each object is encrypted with a unique data key, which is itself encrypted with a KMS master key. This envelope encryption ensures that compromise of a single data key exposes only one object.

RDS encryption. Database volumes are encrypted using AES-256 with KMS keys. This encrypts not just the database files but also automated backups, read replicas, and snapshots. Once enabled, encryption cannot be disabled — a useful property for compliance.

EBS volume encryption. Any temporary storage used during document processing (such as PDF merging) is encrypted at the volume level, ensuring that document data is never written to unencrypted storage, even transiently.

Key Management

Encryption is only as strong as its key management. A perfectly encrypted document is worthless if the key is stored alongside it, accessible to anyone who can access the encrypted data. Key management for document signing platforms should adhere to several principles:

1. Separation of key management from data storage — keys should be managed by a dedicated service (such as AWS KMS or an HSM) that is separate from the service that stores encrypted data. Access to keys should require separate credentials and authorisation from access to data.
2. Automatic key rotation — master keys should be rotated automatically on a regular schedule (typically annually). AWS KMS supports automatic annual rotation, which creates a new key version while retaining the ability to decrypt data encrypted with previous versions.
3. Access controls on key usage — KMS key policies should restrict which services and principals can use each key for encryption and decryption. A document signing platform should use dedicated keys, not shared account-wide keys.
4. Audit logging of key usage — every use of an encryption key should be logged. In AWS, CloudTrail records all KMS API calls, providing an audit trail of who decrypted what and when. This is critical for demonstrating to regulators that access to encrypted data is controlled and monitored.

The question a regulator will ask is not "do you encrypt data?" It is "who can decrypt it, and how do you know?"

NCSC Guidelines

The National Cyber Security Centre publishes guidance on cryptographic standards that is particularly relevant to government and regulated industry platforms. Key NCSC recommendations include:

• Algorithm selection — use AES with 128-bit or 256-bit keys for symmetric encryption, RSA with at least 2048-bit keys (4096 preferred) for asymmetric encryption, and SHA-256 or SHA-384 for hashing. Avoid MD5 and SHA-1 entirely.
• Protocol selection — use TLS 1.2 or 1.3 for data in transit. Disable TLS 1.0 and 1.1. Use HSTS headers to prevent protocol downgrade attacks.
• Key management — use hardware security modules (HSMs) or cloud-managed key services. Avoid storing keys in application code, configuration files, or environment variables.
• Certificate management — use certificates from trusted certificate authorities, implement certificate transparency monitoring, and automate certificate renewal to prevent expiry-related outages.

Beyond Standard Encryption

For document signing platforms handling particularly sensitive data, several additional cryptographic controls may be appropriate:

Client-side encryption. Documents encrypted by the client before upload ensure that the signing platform never has access to plaintext document content at rest. This is a strong control but adds complexity to the signing workflow, as the platform must decrypt the document for display to signers.

Document-level encryption keys. Rather than encrypting all documents with the same master key, each document (or each campaign) can be encrypted with a unique key. Compromise of one key exposes only one document, not the entire corpus.

Cryptographic audit trail integrity. As discussed in our article on tamper-proof audit trails, hash chains provide cryptographic proof that audit records have not been modified. This is a complementary control to encryption — encryption protects confidentiality, while hash chains protect integrity.

Compliance Mapping

Different regulatory frameworks reference encryption in different terms. The following mapping helps compliance teams understand which encryption controls satisfy which requirements:

• UK GDPR Article 32 — requires "appropriate technical measures" including encryption. AES-256 at rest and TLS 1.3 in transit satisfy this requirement.
• FCA SYSC 13.7 — requires firms to have appropriate information security arrangements. Encryption is explicitly referenced as an expected control.
• PRA Supervisory Statement SS2/21 — references NCSC guidance and expects firms to implement encryption consistent with the sensitivity of the data processed.
• Cyber Essentials Plus — requires encryption for data in transit over untrusted networks. TLS 1.2+ satisfies this requirement.
• ISO 27001 Annex A.10 — requires a policy on the use of cryptographic controls and key management. The encryption implementation and key management practices described above align with ISO 27001 requirements.

Conclusion

Encryption for document signing is not a single technology decision. It is a layered architecture: TLS 1.3 in transit, AES-256 at rest, KMS-managed keys with automatic rotation, audited key access, and cryptographic integrity for audit trails. Each layer addresses a different threat, and each is required by one or more regulatory frameworks. The platforms that get this right are not the ones that encrypt data — nearly every modern platform does that. They are the ones that can explain how they encrypt data, who can decrypt it, and how they know that their encryption has not been compromised.