TL;DR: Identity security now spans three expanding control surfaces—third-party identities, cloud entitlements, and unstructured data access—according to SailPoint. The practical signal is that IAM programmes must extend lifecycle and access controls beyond employees or they will miss the identities now carrying real operational risk.
At a glance
What this is: This is a SailPoint blog arguing that identity security must cover non-employees, cloud infrastructure entitlements, and data access governance together.
Why it matters: It matters because IAM teams cannot treat contractors, cloud permissions, and sensitive data access as separate problems if they want consistent governance across NHI, human, and infrastructure identities.
By the numbers:
- 67% of businesses surveyed said their company’s success depends on contractors.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
👉 Read SailPoint's blog on non-employee risk, CIEM, and data access security
Context
Identity security breaks down when organisations manage employees, contractors, cloud access, and data permissions in separate programmes. That fragmentation leaves gaps in certification, offboarding, and privilege oversight, especially where non-human identities and third parties have direct access to critical systems.
SailPoint’s blog uses the rodeo metaphor to argue that every identity type needs governance, but the real issue is operational scope. As organisations expand into cloud infrastructure and unstructured data, identity programmes need one control model that can follow access across people, services, and resources.
Key questions
Q: How should security teams govern contractor and vendor access without losing oversight?
A: Treat non-employee access as a lifecycle process, not a one-time approval. Require named business sponsors, periodic access recertification, and explicit offboarding when the relationship ends. Contractor access often becomes persistent because no one owns revocation, so governance must make ownership and removal part of the same workflow.
Q: Why do cloud entitlements create governance gaps in IAM programmes?
A: Cloud permissions often change faster than application roles and are spread across multiple platforms, which makes them easy to miss during standard access reviews. When entitlement discovery is separate from certification, organisations can approve the identity while leaving high-risk permissions untouched. That is why cloud access must be governed as identity risk.
Q: What do organisations get wrong about unstructured data access?
A: They often certify user accounts without tracing those accounts to the files, repositories, and collaboration spaces they can actually reach. That leaves sensitive data exposed even when application access looks clean on paper. Effective governance needs data-level visibility, not just login-level control.
Q: Who is accountable when third-party access remains after the business need ends?
A: The business sponsor and the access owner are accountable, not the identity team alone. IAM can provide workflow and visibility, but revocation only happens when ownership is explicit and review outcomes are enforced. Without that accountability, third-party access becomes standing risk.
Technical breakdown
Why non-employee identity governance cannot stay manual
Non-employee governance covers contractors, vendors, partners, and other external identities that often sit outside the clean employee lifecycle. The technical challenge is not just access provisioning. It is matching entitlements, sponsor ownership, and offboarding to identities that may enter and leave on different schedules, often with weaker HR system integration. Without workflow-backed certification and revocation, non-employee access can persist long after the business need has ended, creating latent privilege and audit exposure.
Practical implication: map non-employee identities to a governed lifecycle with named sponsors, periodic review, and explicit revocation triggers.
How CIEM extends identity governance into cloud entitlements
Cloud infrastructure and entitlement management focuses on who can do what inside AWS, Azure, and GCP. In practice, that means discovering permissions, identifying excessive rights, and remediating entitlements that were granted outside normal review cycles. CIEM matters because cloud permissions are often more dynamic and more fragmented than traditional application access. Identity governance has to correlate entitlement risk with the identity that holds it, otherwise the organisation can certify a user while leaving risky cloud privilege untouched.
Practical implication: connect cloud entitlement discovery to governance reviews so excessive permissions are visible before they become standing risk.
Why data access security depends on identity controls
Data access governance extends identity controls to unstructured data, where access is often shared, indirect, or poorly documented. The key technical issue is linkage: the system must connect a person or service identity to the files and repositories it can reach, then monitor whether that access remains appropriate. This is especially important for sensitive data because certification without usage context can miss hidden exposure. Identity governance becomes incomplete if it stops at application access and never reaches the data layer.
Practical implication: include file and repository access in governance reviews so sensitive data permissions are certified alongside application rights.
NHI Mgmt Group analysis
Non-employee access is no longer a side programme. The article correctly treats contractors, vendors, and service providers as part of the identity estate, not as exceptions. That is where most IAM programmes still under-invest, because they assume employee-centric controls will scale to external identities. The governance consequence is that sponsorship, review, and offboarding must be designed for identities that are business-critical but not employee-owned. Practitioners should treat non-employee identity as a first-class governance domain.
Cloud entitlement risk is identity risk, not just infrastructure risk. CIEM matters because cloud permissions create identity-driven attack paths that traditional application-centric governance often misses. The operating model shifts from static account management to continuous entitlement visibility and remediation across AWS, Azure, and GCP. That makes cloud access review a governance problem as much as a cloud-security problem. Practitioners need cloud entitlements inside the same governance conversation as joiner-mover-leaver processes.
Data access governance closes the loop that application-centric IAM leaves open. Identity security is incomplete if it can certify user access but cannot explain or monitor access to sensitive unstructured data. That gap matters because many real exposures now live in files, repositories, and collaboration stores rather than only in applications. The field is moving toward identity governance that spans people, infrastructure, and data together. Practitioners should expect audit questions to follow the data path, not just the login path.
Identity governance is becoming a single control plane across three layers of access. The article points to a broader market truth: organisations are converging on one governance model for non-employees, cloud entitlements, and data access because point tools do not hold the line across the lifecycle. This does not eliminate the need for specialist controls, but it does raise the bar for integration. Practitioners should evaluate whether their IAM programme can certify, remediate, and offboard across all three layers without manual stitching.
Lifecycle discipline is the differentiator between access visibility and access control. The same governance logic applies whether the subject is a contractor, a cloud entitlement, or a sensitive dataset. The difference is where the lifecycle begins and ends. Organisations that cannot connect ownership, review cadence, and revocation to each identity type will keep inheriting risk faster than they can certify it. Practitioners should use lifecycle ownership as the test of programme maturity.
From our research:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, which is why lifecycle ownership matters as much as discovery in identity programmes.
- This is the same control problem visible in the 52 NHI Breaches Analysis: access that is never revoked eventually becomes an exposure path.
What this signals
Non-employee identity will keep absorbing more governance attention as organisations push beyond employee-centric IAM. The practical shift is toward one ownership model for contractors, suppliers, and service providers, because fragmented reviews do not survive real-world offboarding pressure. Teams that already struggle with external access should treat lifecycle ownership as the first maturity step, not an optional enhancement.
Cloud entitlement governance is converging with identity governance. As IAM programmes extend into AWS, Azure, and GCP, the most useful question is not whether access exists, but whether it is discoverable, certifiable, and removable inside the same workflow. That is where the operational boundary of IAM is moving.
Identity programmes that stop at login controls will miss the next audit question. Sensitive data, third-party access, and cloud entitlements are increasingly being judged as one control surface. For teams building the roadmap, the governance gap is not visibility alone but the lack of a connected lifecycle across people, services, and data.
For practitioners
- Define a single non-employee governance workflow Assign sponsors, review cadence, and offboarding triggers for contractors, vendors, and partners so external access does not rely on ad hoc manual cleanup.
- Pull cloud entitlements into identity reviews Link AWS, Azure, and GCP permission discovery to access certification so excessive rights are visible in the same control process as application access.
- Extend certification to sensitive data repositories Include file shares, collaboration platforms, and data stores in access reviews so unstructured data permissions are governed alongside accounts and roles.
- Track third-party access as a lifecycle risk Maintain ownership records for partner and supplier identities, then verify that access is revoked when the commercial relationship or support need ends.
Key takeaways
- Identity governance now has to span non-employees, cloud permissions, and data access in one control model.
- The biggest operational failure is lifecycle drift, where access is granted cleanly but revoked too late or not at all.
- Programmes that cannot certify and offboard across all identity types will continue to carry hidden privilege risk.
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-03 | Third-party and secret exposure risks map to NHI lifecycle and rotation controls. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions management is central to contractor, cloud, and data governance. |
| NIST Zero Trust (SP 800-207) | PR.AC-1 | Continuous verification supports governance across multiple identity types and resource layers. |
Map non-employee, cloud, and data access reviews to PR.AC-4 and enforce least privilege through certification.
Key terms
- Non-employee identity: A non-employee identity is any account or access relationship belonging to a contractor, vendor, partner, or other external party. These identities often sit outside human HR workflows, so governance depends on sponsorship, certification, and explicit removal when the relationship ends.
- Cloud entitlement: A cloud entitlement is a permission or right granted within a cloud platform, such as the ability to read, modify, or administer resources. Entitlements are often more dynamic than application roles, which is why they need continuous discovery and review inside IAM governance.
- Data access governance: Data access governance is the practice of controlling who can reach sensitive data and proving that access remains appropriate over time. It extends identity governance into files, repositories, and collaboration stores where exposure can persist even when application access looks well managed.
- Lifecycle offboarding: Lifecycle offboarding is the controlled removal of access when an identity is no longer needed. For contractors, cloud accounts, and other non-human identities, offboarding is a security control, not an administrative task, because unreleased access becomes standing risk.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by SailPoint: Blog roping in identity security threats with SailPoint solutions. Read the original.
Published by the NHIMG editorial team on 2025-12-10.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org