A common warning sign is any design where the service can decrypt user data, recover keys, or hold secrets needed for sign in. Another sign is that compromise of the provider would automatically expose customer content. Secure systems make it impossible for the operator to learn the customer’s secrets from stored data, logs, or infrastructure access.
When a security product can reach customer secrets instead of just protecting them
The core issue is not whether the provider stores data, but whether the product’s design lets the operator observe, decrypt, reconstruct, or reuse customer secrets. If the vendor’s infrastructure, support access, logs, or recovery paths can reveal those secrets, the product is crossing from protection into custodianship in a way that creates unnecessary exposure.
That distinction matters because customers often assume a security product can inspect risk without gaining durable access to the protected material itself. When the provider can also read the secrets, the product’s trust model is much weaker than its marketing suggests.
Design patterns that usually mean the provider has too much access
One sign is any architecture where the service needs plaintext credentials, long-lived decryption capability, or recovery data that can recreate the secret later. Another is a product that requires broad operator visibility into stored customer data to function, especially when that visibility is not technically required for the control outcome.
Look closely at where secrets are handled during onboarding, scanning, alerting, backup, and support. If the product can decrypt user data, recover keys, or rely on shared operator-held material for sign-in or recovery, then the provider can often see more than the customer intended. That is a strong indicator that the service is not truly secretless.
Products that rely on broad support access, central logging of sensitive material, or shared administrative channels are especially concerning. The question is not whether the vendor promises restraint, but whether the system makes secret exposure possible from stored data, telemetry, or infrastructure access.
What a safer access model looks like in practice
A better design keeps the provider outside the secret boundary. The service should be able to verify, route, or broker access without learning the secret itself, and it should avoid holding reusable material that would let an operator impersonate the customer or decrypt protected content.
Practitioners should prefer systems where secrets are customer-controlled, narrowly scoped, short-lived, and technically bounded. That usually means strong separation between metadata and secret material, support workflows that do not require plaintext access, and recovery paths that cannot be turned into general operator decryption rights. Guidance in Secrets Management Guide and the Static vs Dynamic Secrets section is useful here because long-lived shared material tends to expand the provider’s blast radius.
For product selection, a practical test is whether the vendor can describe its access path without saying, in effect, “we can decrypt everything if needed.” If that is part of the operating model, the customer should treat the control as provider-visible rather than provider-blind. The API Key Management Guide is especially relevant when the product depends on bearer credentials, because scope, expiry, and revocation determine how much damage follows from disclosure.
Risk and Threat Considerations
The main risk is blast radius: if the provider or its admin path is compromised, the attacker may inherit access to every customer secret the service can see or reconstruct. That converts a single vendor weakness into a broad disclosure event, even when customers themselves never handled the secret insecurely.
Failure mechanism: The product stores, decrypts, logs, or recovers secrets in a way that gives the operator durable access, so compromise of the provider, support channel, backup set, or privileged tooling exposes customer material at scale.
Impact: Attackers can steal secrets, impersonate customers, pivot into connected systems, and expose content that customers assumed was insulated from the service provider.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Provider access to customer secrets is fundamentally a secret-leakage problem. |
| NHI-05 — Overprivileged NHI | Vendor systems or service identities with broad access can expose more secrets than needed. | |
| NHI-07 — Long-Lived Secrets | Long-lived shared material increases the chance that provider access becomes durable exposure. | |
| Recommendation — Eliminate provider-visible secret paths and keep decryption or recovery outside operator reach. Reduce operator and service permissions to the minimum needed for delivery. Replace long-lived shared secrets with short-lived, customer-controlled alternatives. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secret storage, rotation, and recovery are central when a product can access customer credentials. |
| AC-6 — Least Privilege | Provider tooling should not have broad access to customer secrets or recovery paths. | |
| SC-28 — Protection of Information at Rest | If stored data can be decrypted by the operator, the protection boundary is weak. | |
| Recommendation — Manage authenticators so the provider never needs reusable customer secret material. Restrict administrative access to the smallest set of functions and data. Protect stored customer secrets so infrastructure access does not reveal plaintext. | ||
| OWASP ASVS | V14 — Data Protection | This question concerns whether sensitive data remains inaccessible to the operator. |
| Recommendation — Verify that sensitive data handling prevents vendor-side exposure and plaintext recovery. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Secret exposure through product design is a data protection failure with direct operational impact. |
| CIS-6 — Access Control Management | Operator access to customer secrets must be narrowly controlled and reviewable. | |
| Recommendation — Classify and protect customer secrets so support and telemetry paths cannot expose them. Limit provider access paths and revoke any standing access that can reach secret material. | ||
Practitioner Guidance
What to verify: Ask whether the provider can demonstrate a zero-knowledge or customer-held model for the actual secret path, not just for marketing copy. The important evidence is whether the operator can read plaintext, recover keys, or replay credentials during support or disaster recovery.
Decision rule: If the product can authenticate on the customer’s behalf, decrypt customer data, or retrieve secrets needed for access, treat that as a higher-risk design unless the exposure is tightly bounded, short-lived, and fully customer-controlled.
Practitioner takeaway: The safest secret-handling design is one where the provider can operate the service without gaining the power to impersonate the customer or recover the protected secret later.
Related resources from NHI Mgmt Group
- How should security teams decide whether JIT access is safe for non-human identities?
- How do security teams know whether secrets access is too broad?
- How should security teams implement just-in-time access without creating too much friction?
- How do security teams know if identity provider API access is too broad?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
