Employee-created SaaS identities increase risk because they bypass central onboarding, policy enforcement, and deprovisioning. That creates blind spots around who can access what, where company data is flowing, and whether accounts have strong authentication. When attackers exploit weak passwords, password reuse, missing MFA, or account sharing, unmanaged identities become easier entry points into business systems.
Why unmanaged SaaS identities become security blind spots
Employee-created SaaS accounts are risky because they often exist outside the systems that normally create, name, approve, and review access. Once a user can spin up a separate SaaS tenant or app login without central oversight, security teams lose a reliable inventory of who owns the account, what permissions it has, whether it is still needed, and whether company data is being stored or shared there.
That blind spot is not just administrative. It breaks the assumptions behind access governance: you cannot review what you do not know exists, and you cannot revoke access cleanly if the account was never onboarded into the normal lifecycle. In practice, these identities may outlive the employee’s role, the project they supported, or even the person who created them. The result is lingering access paths that evade normal joiner, mover, and leaver controls.
Unmanaged SaaS identities also make authentication posture harder to enforce. A centrally managed system can require stronger sign-in standards, but a self-created account may rely on weak passwords, reused passwords, personal email recovery, or missing MFA. That is why unmanaged SaaS access so often becomes the weak link that attackers look for first, especially when the account has legitimate business data or cross-system integrations attached to it.
Employee-created SaaS identities are also difficult to monitor because they sit in the overlap between business productivity and security control. The security team may see the vendor category, but not the actual data flow, sharing settings, delegated access, or third-party links behind the account. That makes the identity itself, and the data it can reach, harder to classify and harder to defend.
Risk and Threat Considerations
These identities create a concentrated exposure point because one unmanaged account can combine weak authentication, excessive permissions, and unknown data placement. If an attacker guesses or reuses a password, steals a token, or compromises a linked mailbox, the account can become a foothold into SaaS data, connected apps, and downstream business workflows.
Failure mechanism: The identity bypasses central governance, so provisioning, MFA enforcement, logging, and deprovisioning do not happen consistently. That leaves an account that can persist after role changes, employee departure, or vendor sprawl, while still retaining access to business data and integrated services.
Impact: Attackers gain easier initial access and defenders lose visibility into where the compromise spread. The practical consequence is higher likelihood of unauthorized data access, lateral movement through connected SaaS tools, and delayed containment because the account was never fully under IT control.
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 CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Discovery and Inventory | Unmanaged SaaS accounts are hidden identities that must be discovered and inventoried. |
| NHI-02 — Lifecycle and Offboarding | The risk comes from identities that bypass joiner-mover-leaver and revocation processes. | |
| NHI-05 — Secrets and Credential Hygiene | Weak passwords, reuse, missing MFA, and shared access are key failure modes for unmanaged accounts. | |
| Recommendation — Inventory employee-created SaaS identities and flag any account outside centralized ownership. Tie every SaaS identity to an owner and enforce revocation on role change or exit. Require strong authentication and eliminate shared credentials for all SaaS identities. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Central access control is bypassed when users create SaaS identities outside IT oversight. |
| ID.AM — Asset Management | Unknown SaaS identities create inventory gaps for accounts, data flows, and dependencies. | |
| PR.PT — Protective Technology | MFA, logging, and account controls are core protections that unmanaged SaaS identities often evade. | |
| Recommendation — Enforce centralized access policies for SaaS identities and connected applications. Maintain an accurate inventory of sanctioned SaaS identities and their data connections. Apply protective controls such as MFA, logging, and session safeguards to all SaaS accounts. | ||
| CIS Controls v8 | 6 — Access Control Management | CIS Control 6 addresses managing and revoking access paths, which unmanaged SaaS identities bypass. |
| 5 — Account Management | Employee-created SaaS identities are an account-management problem when ownership and deprovisioning are unclear. | |
| 8 — Audit Log Management | Unmanaged SaaS identities reduce visibility, so logging and review become essential for detection. | |
| Recommendation — Use centralized access management to approve, review, and remove SaaS access paths. Track SaaS accounts by owner and remove dormant or orphaned access promptly. Ensure SaaS access and administrative actions are logged and reviewed centrally. | ||
Practitioner Guidance
What to prioritise: Start with discovery and ownership. If an employee can create SaaS access without a ticket, approval, or SSO tie-in, treat that identity as a governance gap even before you know whether it is malicious.
What to verify: Check whether the account can be tied to a business owner, whether MFA is enforced, whether the app stores company data, and whether offboarding would actually revoke access and connected tokens. A good test is whether you could answer those questions from your standard IAM records alone.
Common mistake: Treating “shadow” SaaS accounts as harmless because they are productivity tools. In reality, the risk often comes from account age, weak recovery paths, and linked integrations, not from the app brand itself.
Practitioner takeaway: The control objective is not to ban every employee-created SaaS use case, it is to ensure any identity that can reach company data is discoverable, attributable, enforceable, and revocable on the same timeline as centrally managed access.
Related resources from NHI Mgmt Group
- Why do browser based non human identities increase risk when they operate outside traditional identity tools?
- Why do non-human identities increase identity blast radius?
- Why do autonomous agents increase identity risk when they run on employee devices?
- Why do SaaS and AI connections outside SSO increase identity risk?
