Application-layer storage only protects tokens if the app behaves correctly, while data-layer custody controls require every token read or write to pass tenant, project, and account verification. That distinction matters because it limits who can access secrets, reduces exposure from internal tooling, and preserves isolation even when parts of the system are compromised.
Why application-layer storage and data-layer custody controls are different
Application-layer storage keeps the token with the application’s own logic, so protection depends on the app’s behavior, code paths, and surrounding runtime. Data-layer custody controls move the trust decision into the storage or access service itself, so token reads and writes are checked against tenant, project, and account context before access is granted. That shifts enforcement from “the app should do the right thing” to “the platform must prove the request is allowed.”
That difference matters most when multiple tenants, integrations, or internal tools share the same environment. If the application is compromised or misroutes a request, application-layer storage can still expose tokens that are technically “inside” the app boundary. Custody controls at the data layer make unauthorized retrieval harder even when a caller reaches the storage path.
For OAuth in particular, the token is not just a blob of data, it is a bearer of delegated access. Guidance such as RFC 6749: The OAuth 2.0 Authorization Framework and RFC 9700: Best Current Practice for OAuth 2.0 Security makes that delegation model sensitive to theft, replay, and overbroad handling. The custody question is therefore not only where the token lives, but who can prove they are allowed to touch it.
What changes in the control boundary
Application-layer storage is usually easier to build, but it inherits the app’s trust boundary. Once a service has token access, any bug in authorization checks, request routing, or administrative tooling can widen exposure. It is common to see this model rely on the application to decide whether a token belongs to the right tenant or account.
Data-layer custody controls reduce that dependency by making the storage system enforce ownership and scope before data is returned or written. In practice, the platform can require contextual verification, so a token cannot be fetched simply because the caller has a network path or application session. That is a stronger pattern when the goal is to preserve isolation across tenants or business units.
This is why many security teams treat custody controls as a defense against internal misuse as well as external compromise. A request that never satisfies the storage layer’s ownership checks cannot be rescued by a later application-side review. The difference is structural, not cosmetic.
Why this distinction changes real-world exposure
Tokens tend to be high-value because they often outlive a single session and can unlock downstream APIs, SaaS integrations, or shared data flows. If those tokens are exposed through an application bug, a compromised admin path, or an internal helper service, the resulting access can be broader than the original user intended. A custody layer narrows the set of request paths that can ever reveal the token.
Internal readers should also think about blast radius. If the storage layer verifies tenant, project, and account before every read or write, a compromised component is less likely to pivot laterally across boundaries. That is especially important where token stores, admin consoles, and integration services sit near sensitive operational data.
For broader identity and secret handling patterns, NHIMG’s Ultimate Guide to NHIs, What are Non-Human Identities is useful background because it places tokens, service accounts, and machine identities in the same operational risk model. The same logic appears in Ultimate Guide to NHIs, Standards, which connects these custody decisions to concrete security controls and zero trust thinking.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token custody depends on controlling creation, storage, rotation, and revocation of authenticators. |
| AC-6 — Least Privilege | Custody controls limit which identities or services can read sensitive tokens. | |
| Recommendation — Manage token lifecycle tightly and rotate or revoke tokens when custody boundaries change. Restrict token read and write paths to the minimum required privileges. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is fundamentally about enforcing access boundaries for sensitive token data. |
| Recommendation — Define and enforce access rules for token storage and retrieval. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Token custody requires managing who can access sensitive credentials and secrets. |
| Recommendation — Review and limit access paths to token stores and integration systems. | ||
Practitioner Guidance
What to verify: Confirm whether the token store enforces ownership at the storage boundary or whether the application must reconstruct tenant and account checks on every access. If the latter is true, treat the app as part of the control plane rather than as a simple consumer of secrets.
Decision rule: If a token can authorize production access, prefer custody controls that make unauthorized reads fail before application logic is reached. If the token is low impact and tightly scoped, application-layer storage may be acceptable, but only with strong monitoring and short token lifetimes.
What good looks like: The best outcome is a storage service that can prove every token access is tied to the correct tenant, project, and account, with auditable access traces and clear denial behavior for mismatched context. That makes privilege mistakes easier to detect and harder to turn into cross-boundary exposure.
Practitioner takeaway: Application-layer storage trusts the app to behave; data-layer custody trusts the platform to enforce isolation. When tokens can unlock meaningful downstream access, the safer design is the one that keeps ownership checks at the boundary that actually stores the secret.
Related resources from NHI Mgmt Group
- What is the difference between human identity controls and OAuth application governance?
- What is the difference between enforcing security at the database layer and handling it in application code?
- What is the difference between native Microsoft Purview controls and a continuous data intelligence layer?
- What is the difference between the token handler pattern and putting OAuth tokens directly in a single-page application?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
