Organisations should ask how the vendor compartmentalises tenants, how it protects secrets and seeds, what internal access exists to the infrastructure, and which independent audits or tests validate those controls. Those questions turn trust into evidence.
Why This Matters for Security Teams
cloud identity services sit at the centre of trust for users, workloads, APIs, and increasingly AI agents. The right questions are not limited to features; they test whether the provider can prove tenant isolation, control privileged internal access, and defend the secrets that underpin authentication. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it pushes teams toward outcomes such as governance, protection, and continuous assurance rather than blind reliance on branding.
This is especially important because identity failures usually become infrastructure failures. NHIMG’s Ultimate Guide to NHIs shows how often organisations mismanage non-human identities, secrets, and revocation, which is directly relevant when a cloud identity service becomes the control plane for access decisions. If the vendor cannot explain who can reach production systems, how break-glass paths are governed, or how tenant boundaries are enforced, then the service is asking customers to accept trust without evidence. In practice, many security teams encounter that gap only after a support escalation or breach review has already exposed it.
How It Works in Practice
Good vendor due diligence asks for proof, not promises. Start with tenant separation: ask whether customer data, signing keys, logs, and control-plane components are isolated per tenant or shared across a multitenant core, and how blast radius is limited if one tenant is compromised. Then move to secrets and seeds. A cloud identity provider should be able to explain how root keys, recovery seeds, token-signing material, and backup material are generated, stored, rotated, and destroyed, and whether any operator can ever view them in cleartext.
Next, examine internal access. Ask what production access exists for engineers, SREs, support staff, and contractors; whether access is time-bound; whether sessions are recorded; and whether privileged operations require just-in-time approval. The provider should also describe how it detects abuse from its own staff and how separation of duties is enforced for schema changes, incident response, and customer support actions. This is where independent validation matters. Look for SOC 2 reports, penetration tests, red-team exercises, and any findings tied to identity-specific risks rather than generic hosting claims. NHIMG’s 52 NHI Breaches Analysis is a useful reminder that identity compromise often starts with weak lifecycle control, not sophisticated malware.
- Ask how tenant keys are separated and whether any shared signing infrastructure exists.
- Ask whether support can reset, export, or bypass customer-controlled identity factors.
- Ask how internal admin access is granted, logged, reviewed, and revoked.
- Ask which audits tested identity-specific controls, not just general uptime or compliance.
These controls tend to break down when a provider relies on a highly shared operational model with limited customer visibility into staff actions and recovery paths.
Common Variations and Edge Cases
Tighter identity controls often increase friction, so organisations need to balance operational speed against loss of assurance. That tradeoff becomes sharper for startups, regulated industries, and hybrid environments where the cloud identity service also brokers federation, device trust, and workload access. Best practice is evolving, and there is no universal standard for every deployment model yet, especially where the provider offers both SaaS administration and managed infrastructure services.
One common edge case is delegated administration. A provider may claim customers control their own tenants while still retaining broad internal break-glass access. Another is key management: some services outsource root material to external HSMs, while others keep recovery capabilities in-house. The security question is not which architecture sounds cleaner; it is whether the provider can document who can use recovery paths, under what approvals, and with what audit trail. For deeper context on how identity failures cascade into operational compromise, the Azure Key Vault privilege escalation exposure and the Snowflake breach illustrate why secrets handling and privileged access must be evaluated together.
Another edge case is evidence quality. Some vendors provide certifications but not control design detail. Others provide detail but no independent validation. The strongest procurement posture combines both, then maps the answers to internal risk acceptance. If the provider cannot answer clearly, the safe assumption is that the service is not yet ready for high-trust workloads.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Vendor due diligence is a governance and risk management decision. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Cloud identity services often fail through weak secret handling and lifecycle control. |
| NIST SP 800-63 | 4.4 | Assurance depends on how authenticators, recovery, and lifecycle events are controlled. |
Require documented risk acceptance and third-party evidence before onboarding the cloud identity service.
