Server-managed encryption protects data while it is stored by the service. It does not, by itself, prevent an authorized application, its operator or a compromised service identity from receiving plaintext through an ordinary read. For a code-security vendor, a statement such as “encrypted with KMS” answers one question about stored objects or database records; it does not answer who can read source, prompts, findings or backups. The conclusion changes if the customer encrypts content before the vendor receives it and retains exclusive decryption control, but that is a different design requiring its own workflow and proof. AWS describes server-side S3 encryption as a storage feature and explains how S3 uses KMS data keys for SSE-KMS (S3 SSE-KMS documentation).
Use this distinction when a procurement response says “vendor unreadable,” “customer controlled” or “encrypted at rest.” Ask for the exact encryption mode, key owner, read path and administrative access. A key name or certificate is not an access test.
Follow a normal read before discussing key ownership
In server-side encryption, the storage service handles encryption and decryption as part of its service workflow. S3 supports S3-managed keys and SSE-KMS; DynamoDB encrypts its table data at rest with AWS KMS-backed mechanisms (S3 server-side encryption, DynamoDB encryption at rest). The application calls a data API. If that read is authorized, it receives usable data. KMS protects the key path for the storage service; it is not a substitute for deciding whether the caller may read the object, row or report section.
This matters for tenant separation. If two customers share a table, one table encryption key may protect media at rest while application authorization and IAM still decide whether a tenant A request can retrieve tenant B's row. A wrong key in a query, an overly broad backup role or a support export can defeat confidentiality despite correct at-rest encryption. Conversely, a denied data API read should remain denied even if the caller has some KMS permission. Review the actual service and policy combination, including resource policies and administrative roles.
Illustrative case; all names and settings are invented. Bluefen Security stores source-derived finding sections in a DynamoDB table encrypted with an AWS managed KMS key. It stores a temporary source archive in an S3 bucket using SSE-KMS. Its sales questionnaire says “only customers can decrypt their findings.” Yet the application reads finding text to render its web interface, and a support role can call a broad export endpoint. The architecture shows the vendor service has a plaintext path. The encryption choice may still be appropriate protection for stored media, but the specific “only customers” claim requires a different design or a corrected statement.
The reviewer records the claim by threat and operation:
| Claim to review | What the named encryption helps protect | What to ask for next |
|---|---|---|
| “The S3 source archive uses SSE-KMS” | Stored object bytes under the S3/KMS design | Who can GetObject and use the key? What roles can copy, replicate or restore the object? |
| “The findings table is encrypted at rest” | Durable table media, indexes and supported backups | Which roles can read rows, export the table or restore a backup? How are tenant and section rights checked? |
| “Each tenant has a separate KMS key” | Potentially narrower cryptographic control, depending on key policy and data layout | Can the vendor service use each key? Are data copies, logs and reports encrypted under the same rule? |
| “The customer controls the key” | A customer-managed key may enable policy and revocation choices | Can the vendor request decrypt through an authorized service grant? What is the effect of disabling the key? |
| “The vendor cannot read plaintext” | Nothing follows from server-side encryption alone | Show encryption before vendor receipt, exclusive customer decryption authority, and a workflow proving the vendor has no plaintext path |
The table is a review tool, not a verdict on a real provider. AWS explains that DynamoDB can use an AWS owned, AWS managed or customer managed key, and that key choice affects management and availability (DynamoDB encryption usage notes). It does not erase the need for application and IAM authorization.
Separate three designs that sound similar
Provider-managed server-side encryption. A cloud service encrypts stored data and manages the key path according to its service design. This is a useful baseline against unauthorized access to underlying media. The reader should still ask who is authorized through the service API. For S3, the distinction between SSE-S3 and SSE-KMS affects key management and permissions; neither label alone tells you what the vendor's own application can display.
Customer-managed KMS key used by a server-side service. First identify whose AWS account owns the key. AWS “customer managed” describes management relative to AWS; a key managed by the SaaS vendor in its account is not automatically controlled by the SaaS buyer. The actual key policy, grants and administrative rights determine who can change, audit or disable it. The service still must be able to decrypt data keys to fulfill authorized reads. AWS's data-key explanation shows that the plaintext data key is used outside KMS for encryption and decryption. Before accepting “customer controlled,” determine who may create grants, call through the service, change the key policy and restore data. Disabling a key may make data unavailable; it does not retroactively remove plaintext already delivered, copied or logged.
Client-side or application-layer encryption before the vendor receives content. Here the data is encrypted before storage and the storage provider sees ciphertext for protected fields. This can create a stronger separation if the vendor never receives the decrypting key or plaintext. It also limits features that need to inspect content, such as source analysis, search, report rendering and support. AWS describes client-side protection for DynamoDB items through its Database Encryption SDK. The SDK's existence is not proof that a particular SaaS uses it or that all fields and copies are covered. Ask for the actual field map, key custody and authorized viewer flow.
An optional customer key in a vendor product may instead be an additional server-side key that the vendor service can use. That can be valuable without being vendor-blind. Require the vendor to say which design it means.
Walk two reads and one misleading revocation claim
Bluefen supplies a synthetic source archive pilot/J7/source.zip. The storage configuration names SSE-KMS key K1. The normal reader is a vendor task role with permission to retrieve that object and use K1 through the storage workflow. The ordinary application call returns plaintext to the task. The customer never supplies a decryption key to that task.
That successful read disproves “only customers can decrypt” under this design. It does not show that encryption is broken. The service is doing exactly what authorized server-side encryption is designed to do. AWS's SSE-KMS documentation describes S3's encrypted data-key workflow and the KMS permission needed for downloading protected objects.
The review packet should distinguish these cases:
| Synthetic principal and operation | Required evidence | Interpretation |
|---|---|---|
| Task role reads permitted J7 archive | Object access plus relevant KMS authorization; plaintext reaches task | Storage encryption works with a vendor plaintext path. |
| Ordinary support role reads J7 directly | No effective object read permission | Must remain denied; possessing a key-related permission alone is not object authorization. |
| Broad support export endpoint returns finding text | Endpoint runs under an application role allowed to read the encrypted findings table | Customer-facing support toggle is insufficient if this route bypasses it. Fix delegation/access, not encryption terminology. |
| Recovery role restores a source-bearing backup | Separate restore authority, key availability and destination policy | A privileged exception to inventory; it is not cleared by the task-role denial. |
These are planned checks using synthetic content, not executed results. A denied S3 operation and a denied application export exercise different paths. A demonstration of either cannot stand in for the other.
Now Bluefen offers a customer-managed key and says, “You can instantly revoke all reads by disabling it.” The reviewer asks which service, which key, which copies and which cache behavior support that word instantly. DynamoDB, for example, documents caching plaintext table keys and rechecking KMS after a period of inactivity; its encryption usage notes describe the service-specific behavior. An application may also retain plaintext already read. Do not invent one immediate-revocation guarantee across S3, DynamoDB, caches and reports.
The proposed customer-key design may still give useful control over future decrypt operations and resource availability. Its acceptance record must name the actual operation stopped, the demonstrated timing and remaining plaintext copies. Use application authorization to stop new customer delivery while separately handling service/key availability. Neither disabling a key nor deleting a file recalls a downloaded report or establishes physical erasure.
Correct the questionnaire without weakening the control
Bluefen replaces its original sentence with:
“The named source archive and finding store use server-side encryption at rest. Authorized vendor workloads receive plaintext to perform analysis and render permitted findings. Support and recovery access are separately controlled and audited. A customer-managed key, where offered and evidenced for the named resource, does not by itself make the vendor unable to read content.”
This answer helps a buyer make a real choice. If the requirement is vendor-unreadable content, the architecture must keep plaintext and decryption authority out of the vendor's reach throughout the relevant workflow. If the requirement is controlled vendor processing with encrypted storage, Bluefen can meet it with an appropriate access design and evidence. Changing a key's ownership label cannot bridge the two requirements.
Ask which threat the additional key control changes
Before buying a customer-key feature, Bluefen's buyer should name the intended benefit. The goal might be controlling future access to one storage resource, separating administrative duties, producing an audit trail for key use, or requiring a customer action before analysis can resume. Each is a different control objective. “More encryption” does not say which outcome the design delivers.
Use the normal read map to ask how the proposed feature changes it. Which principal now needs an additional permission? Which administrator can restore that permission? Which source-bearing stores use the key, and which reports or logs remain outside it? What is the recovery process if the key becomes unavailable? The answers should identify both the security effect and the expected product interruption.
A small synthetic exercise can make the distinction visible without handling private source. Establish an allowed read, apply the agreed key or access restriction, then observe the specific operations and timing described by the service design. Keep cached or already delivered content separate. The result may demonstrate a useful future-access control while leaving earlier plaintext copies untouched.
The buyer can then compare that evidenced benefit with the requirement. If the requirement is that vendor staff cannot obtain plaintext at any point, a storage key the vendor workload can use still leaves the central mismatch. If controlled vendor processing is acceptable, the key feature can be evaluated alongside ordinary authorization, support restrictions and recovery access on its actual merits.
What the buyer can decide
Bluefen's customer can accept server-managed encryption as one storage control while requiring a narrower support role and an accurate vendor-access statement. If the policy requires that the vendor cannot inspect finding content, the buyer must ask whether a customer-held decryption design is feasible for the desired analysis and reporting workflow. If it is not, the issue is a requirement mismatch, not a missing phrase in the contract.
Next action: choose one source-bearing storage path and trace a permitted read from identity through service authorization, KMS and plaintext response. Then review source retention and deletion claims and tenant isolation in a code-security SaaS.