A regulated asset manager requires that the encryption keys protecting its data in a SaaS application never be in the SaaS provider's custody, so that the provider cannot decrypt the data even if compelled. Which key management approach meets this requirement?
Select an answer to reveal the explanation.
Short Explanation
Bringing your own padlock is nice, but if you hand the landlord the key afterward, the landlord can still open the door. Hold your own key means the key never leaves your pocket. The trap is BYOK, where the key you generated ends up in the provider's key service.
Full Explanation
Key custody determines who can decrypt. With hold your own key, keys are generated and kept in a hardware security module or key service the customer controls, outside the provider's environment, and the SaaS application must request cryptographic operations from it. Because the provider never holds the keys, it cannot decrypt the data on its own, and the customer can revoke access by withholding the keys. Bring your own key improves control over key generation and lifecycle, but the key is imported into the provider's key management service, so the provider's systems hold it and can use it; it does not meet a never-in-custody requirement. Provider-managed encryption at rest leaves keys entirely with the provider, protecting against stolen media but not against the provider itself or compelled disclosure. A separate key administrator role in the same tenant is separation of duties within the customer's configuration, yet the keys still sit inside the provider's platform. Exam caveat: hold your own key often limits SaaS features that need plaintext, such as search, and adds availability risk if the external key service fails. Operational check: confirm key requests from the SaaS service are logged in the customer's HSM and that a revocation test makes the data unreadable.