Security architecture
Customer-managed keys are not zero-knowledge
Adobe Acrobat Sign's new BYOK feature strengthens encryption at rest. Inklok takes a different approach with managed zero-knowledge completed agreements included on every plan.
Adobe Acrobat Sign deployed version 17.2 on September 8, 2026. One of its new enterprise security features is Customer Managed Encryption. Eligible customers can supply an AWS KMS key that Acrobat Sign uses to protect supported agreement content at rest.
It is a worthwhile improvement. Customers gain more control over an important part of Adobe's encryption at rest setup. It is still not zero-knowledge, because Acrobat Sign can decrypt protected content when its workflows need it.
We built Inklok around a different premise. Completed agreements use a zero-knowledge model so Inklok does not keep an independent key that can read the information participants add during signing. Customers get that protection without setting up or operating their own KMS integration.
Two different security boundaries
Both approaches improve security, but they handle trust and key management differently.
Adobe customer-managed encryption
The customer controls a critical key. Acrobat Sign can still process plaintext.
- The customer provisions and maintains an AWS KMS key and access credentials
- Supported stored content is protected through that customer-controlled key path
- Acrobat Sign decrypts content when supported workflows require it
Inklok managed zero-knowledge agreements
Completed agreements remain readable to authorized participants without giving Inklok an independent decryption key.
- The browser encrypts information entered during signing before upload
- Inklok manages the agreement workflow while storing encrypted participant data
- Authorized participant identity is required to decrypt the completed agreement data
What Adobe's new BYOK model improves
Adobe's documentation says Customer Managed Encryption uses an organization's AWS KMS customer-managed key to protect supported Acrobat Sign content at rest. The initial release covers content such as agreement PDFs, templates, thumbnails, and temporary workflow files.
This puts an important part of the key lifecycle under the customer's control, including rotation and revocation. For an organization that already runs a centralized AWS KMS program, that can fit naturally into its existing security operations.
Adobe is also clear about the limits. The feature is not end-to-end encryption. Acrobat Sign still decrypts protected content when needed for agreement workflows, and form-field data is not protected by the customer-managed key in the current release.
That is the intended design. BYOK adds control and governance to encryption at rest while preserving Acrobat Sign's ability to process agreement content on the server.
Adobe's documentation has the full implementation details. See the v17.2 release notes, configuration documentation, and current limitations.
Customer-managed also means customer-operated
The added control comes with work on the customer side. Adobe's setup documentation requires the customer to create and maintain an AWS KMS key, configure IAM permissions and credentials for Acrobat Sign, keep that access available, and manage key and credential lifecycle tasks.
Adobe also warns that protected agreement operations can become unavailable if Acrobat Sign loses access to the KMS key or its AWS credentials. The customer has to restore that access before those operations can resume.
Organizations with mature KMS operations may be comfortable with that responsibility. Others need to account for the additional setup, monitoring, and recovery work.
Inklok goes further, and manages it for you
We chose a different model for completed agreements. Instead of asking customers to provide a server-side key that Inklok can use, we designed the platform so Inklok does not hold an independent key capable of reading the participant-provided contents of a completed agreement.
Customers do not need to provision AWS KMS keys, create IAM users, rotate service credentials, or maintain a separate key-management integration. Zero-knowledge protection is part of the managed agreement service.
We handle the hard parts in the product, including participant key orchestration, guest signing, sharing completed agreements with authorized people, preserving access for authorized roles at the sending organization, access on a new device, recovery workflows, and agreement processing without relying on a decryption key held by Inklok.
You should still keep your Inklok Recovery Key as a safeguard for certain account recovery situations. Routine signing, sharing, guest participation, and authorized organizational access are designed to work without asking customers to operate their own cryptographic infrastructure.
How that protects sensitive information
A completed agreement may contain a bank account number, Social Security number, health information, tax ID, or other sensitive information supplied during signing. Inklok encrypts that information in the participant's browser before it reaches our servers.
Inklok receives ciphertext instead of readable participant data. Authorized participants and roles can still access the completed agreement, but Inklok does not have a general-purpose decryption key that lets us read that protected information.
That goes beyond encryption at rest alone. BYOK changes who controls the storage encryption key. Zero-knowledge changes whether the SaaS provider has an independent ability to decrypt the sensitive information inside a completed agreement.
The difference
With Adobe BYOK, the customer supplies a key and Acrobat Sign uses it to strengthen protection for supported stored content.
With Inklok, completed agreements use a zero-knowledge model that does not give Inklok an independent key for participant-provided data. We manage the cryptographic orchestration, so customers get that protection without running their own KMS integration.
Questions worth asking in a security review
When a vendor says sensitive agreement data is encrypted, ask a few more questions:
- What data does the encryption boundary actually cover?
- Where is plaintext created?
- Who controls the keys needed to decrypt it?
- Can the SaaS application obtain plaintext during normal operation?
- What would a backend compromise expose?
- What key-management work falls on the customer?
Encryption matters. The architecture around it determines what it actually protects, who can decrypt the data, and who has to operate the key infrastructure.
Sources and further reading
Zero-knowledge completed agreements without a BYOK project or an extra fee.
Zero-knowledge protection is built into every Inklok plan at no extra charge. We manage the agreement workflow and cryptographic orchestration without keeping an independent key that can read the protected information participants add to completed agreements.