Managed versus unmanaged SaaS

What “managed” means in SaaS governance

Managed SaaS is not just software that a team happens to approve. It is SaaS that is brought into a controllable lifecycle, with a known owner, a sanctioned onboarding path, and the ability to review how it is being used across the organisation.

The key difference is governance, not technology. A managed app sits inside procurement, security, and access processes, so the organisation can decide who may use it, what data it may handle, and how it will be retired or reassessed later.

That makes “managed” a useful boundary for ownership. It tells security, IT, and business teams that the tool is visible enough to support review, rather than being a one-off purchase hidden in a department or project.

What “unmanaged” means and why it matters

Unmanaged SaaS is adopted outside the formal control path, often by a business unit or individual user without central approval. The problem is not only that it may be unknown; it is that the organisation may not know what data it stores, which users can access it, or who is accountable when it changes.

This is where SalesBleed Salesforce Agentforce 2026 is a useful reminder that SaaS can become a trust and access problem when automation, data exposure, and identity are not tightly governed. The same governance gap that leaves an app unmanaged can also leave its connected accounts, permissions, and outbound data paths poorly understood.

Unmanaged SaaS often grows through convenience, shadow IT, or temporary project adoption. Over time, those tools can become business-critical without ever receiving the controls that a managed service would normally receive.

Control differences across the SaaS lifecycle

The managed versus unmanaged distinction becomes most visible at three points: onboarding, operation, and offboarding. Managed SaaS can be inventoried, reviewed, and removed in a repeatable way. Unmanaged SaaS may bypass those steps entirely, which means the organisation can lose visibility into ownership, access, retention, and recovery responsibilities.

For access control, the issue is not only whether a user can sign in. It is whether the organisation can consistently revoke access, limit who can connect, and understand which integrations or shared credentials are still active. That is why formal security controls and identity review processes matter for SaaS as a category, even when the application itself is simple.

Managed SaaS also tends to support better data handling decisions. When a service is known and reviewed, teams can assess where data resides, whether the app is approved for sensitive information, and whether contractual or regulatory expectations are being met.

How to interpret the term in practice

“Managed” and “unmanaged” are not absolute technical states, they are governance states. A SaaS product may be partially managed in one business unit and unmanaged in another, depending on whether procurement, inventory, access control, and review are actually enforced.

That is why the term is best used as a signal about organisational visibility. If a service is unmanaged, the practical question is not just “what is the app?” but “who owns it, what data does it touch, and how would the organisation prove it is still acceptable to use?”

In mature environments, the goal is not to eliminate SaaS sprawl entirely. It is to make sure every SaaS service is either brought under control or explicitly accepted with known risk, ownership, and review expectations.

Risk and Threat Considerations

Unmanaged SaaS creates exposure because control gaps often appear first in ownership, access, and data handling. Once a tool is adopted outside formal review, the organisation may not notice excessive permissions, stale accounts, weak offboarding, or uncontrolled sharing until after data has already moved.

Failure mechanism: The service enters use without central visibility, so access cannot be governed consistently and offboarding becomes incomplete or delayed. That creates a path for lingering accounts, orphaned integrations, and unreviewed data flows.

Impact: Sensitive data can be exposed, access can persist after business need ends, and the organisation may be unable to prove who approved the service or what controls were applied.

Practitioner Guidance

Why practitioners should care: The managed versus unmanaged label is really a control-status indicator. It tells you whether a SaaS service is inside the organisation’s decision, review, and accountability structure, or whether it is operating outside it.

Common misunderstanding: Teams often treat “approved once” as the same as “managed.” In practice, a SaaS service only stays managed if ownership, access, and review remain current as the service, users, and integrations change.

Practitioner takeaway: Use the distinction to drive inventory discipline, access review, and retirement decisions, not just procurement approval.

Related resources from NHI Mgmt Group

• How should security teams manage SaaS access when employees use both managed and unmanaged apps?
• What is the difference between managed SaaS and unmanaged SaaS from a security governance perspective?
• What happens when a FileVault recovery key is needed on a managed Mac versus an unmanaged Mac?
• How do third-party SaaS integrations create NHI risk and how should they be managed?