Cloud & data centres · Cloud Platform · Security Architecture · SaaS Assurance
Prove tenant separation in a multi-tenant cloud key service
Can an operator, software defect, or compromised tenant cross the intended cryptographic boundary?
Operational pain
Per-tenant key labels do not prove separate authorization, wrapping hierarchy, audit visibility, backup, and deletion behavior.
Trigger
Enterprise onboarding, shared-service redesign, or a customer asks for customer-managed custody.
QNSI contribution
Connect the decision to a controlled security path
Use QNSI key and policy records to identify tenant ownership, provider boundary, operations, access roles, and lifecycle evidence.
Decision artifact
A tenant-custody assurance map with tested isolation cases, privileged paths, and residual shared dependencies.
What still requires validation
The provider must perform adversarial authorization tests, recovery tests, deletion verification, and independent architecture review.
External problem context
Primary sources
These sources establish the external requirement or risk context. They do not endorse HEOSSI or prove that QNSI completed this scenario.
Evidence boundary
What this page does—and does not—prove
This is a product evaluation pattern, not a customer case study, certification, legal opinion, regulator endorsement, or claim that a production deployment completed the described work.