Any cloud or SaaS application that falls within a compliance or governance boundary because it is accessed with business credentials. In this article’s context, scope is determined by real access behaviour, not by whether the app was formally onboarded or centrally managed.
Expanded Definition
An in-scope cloud service is not simply any third-party application in a procurement register. In NHI governance, the term applies when a cloud or SaaS service is reachable with business credentials, tokens, API keys, or browser-based identity flows that create real access risk, even if the service was never formally onboarded. That makes scope a function of observed access behaviour, not administrative approval.
This distinction matters because identity teams often focus on managed platforms while shadow SaaS, personal workspaces, and embedded integrations accumulate outside the normal control plane. The OWASP Non-Human Identity Top 10 treats unmanaged access paths and secret exposure as core NHI risks, and the same logic applies to cloud services that are operationally in scope but missing from governance inventories. NHI Management Group research on the Ultimate Guide to NHIs shows that access sprawl is often discovered only after identities are already active across multiple services.
Definitions vary across vendors on whether “in-scope” depends on data residency, procurement status, or authentication method, but in security practice the decisive factor is whether business credentials can reach the service and create governed access. The most common misapplication is treating “not officially onboarded” as “out of scope,” which occurs when an app is used through federated login or stored secrets but is absent from the approved application list.
Examples and Use Cases
Implementing in-scope cloud service classification rigorously often introduces inventory overhead, requiring organisations to weigh governance accuracy against discovery and review cost.
- A marketing SaaS tool accessed by employee SSO is brought into scope because business credentials can read customer exports, even though procurement never registered it.
- A cloud storage bucket connected through a service account is in scope because an NHI can write files there, creating an access path governed by OWASP Non-Human Identity Top 10 guidance.
- A collaboration app used only by one team becomes in scope after an audit shows OAuth tokens granting mailbox and file access, matching the access-behaviour approach described in 230M AWS environment compromise.
- A SaaS analytics platform is marked in scope when a contractor authenticates with federated credentials and can download regulated reports, even though the application is not centrally managed.
- A file-sharing service is pulled into monitoring after secret material is uploaded there, reinforcing lessons from the Azure Key Vault privilege escalation exposure research.
These use cases show why scope should be confirmed from actual authentication and authorisation evidence, not from ownership claims alone.
Why It Matters in NHI Security
In-scope cloud services are where shadow access turns into measurable NHI exposure. When a service is missed during scoping, teams cannot reliably enforce secret rotation, session revocation, least privilege, or logging expectations. That creates blind spots in both human and non-human identity governance, especially where federated access, API tokens, and service accounts overlap.
This is not a theoretical issue. In the 2024 Non-Human Identity Security Report from Aembit, only 19.6% of security professionals expressed strong confidence in their organisation’s ability to securely manage non-human workload identities, and 35.6% cited consistent access across hybrid and multi-cloud environments as their top challenge. Those numbers reflect how quickly scope gaps become operational risk when cloud services are connected through real credentials rather than formal onboarding.
Understanding what is in scope also supports incident response. If a compromised token can reach a cloud app, that app is part of the blast radius whether or not it appears in the CMDB. Organisations typically encounter the full consequence only after a token leak, unauthorized data pull, or lateral movement event, at which point in-scope cloud service classification becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | In-scope cloud services expand the secret and credential exposure surface. |
| NIST CSF 2.0 | ID.AM-1 | Asset management requires knowing which cloud services are actually used. |
| NIST Zero Trust (SP 800-207) | PR.AC | Zero Trust scoping depends on verifying every reachable service and session. |
Inventory services reachable by business credentials and govern their secrets and access paths.
