Software asset management (SAM) and SaaS management platforms (SMPs) answer the same four questions: what software do we have, what does it cost, are we compliant, and is it being used. The difference is the software those questions are asked about. SAM was engineered for installed software and entitlement math. SMPs were engineered for subscriptions and the identities holding them. Pick based on which estate you actually run, and know that for most organizations the honest answer involves both.
Every few weeks, someone evaluating Zluri asks a version of the same question: "Aren't you just a SAM tool for SaaS?" It's a fair question, and the answer is more interesting than a yes or no, because it's really a question about what happened to software itself.
Both disciplines sit within the broader practice of IT asset management, and both exist to answer identical questions. What software does the organization have? What does it cost? Are we compliant with its terms? Is it actually being used? If the questions are the same, why are these two different categories at all?
Because the object of the questions changed. The software SAM was built to manage behaves nothing like the software an SMP was built to manage, and the instruments that work brilliantly for one are structurally blind to the other. Understanding that difference is how you avoid the two expensive mistakes in this space: buying an enterprise SAM suite to control SaaS sprawl, or assuming an SMP will defend you in an Oracle audit.
What SAM Was Built For
Software asset management grew up in the era of installed software and perpetual licensing, and its center of gravity is entitlement complexity.
Consider what a classic SAM tool is actually great at. An IBM license measured in Processor Value Units. Oracle database options licensed per core, with virtualization rules that can silently multiply your liability. Microsoft server licensing with CALs, downgrade rights, and Software Assurance terms. These licensing models are genuinely intricate, the financial stakes of getting them wrong are enormous, and vendors run audit programs designed to find every gap.
So SAM tooling evolved to match:
- Discovery by scanning: Agents and network scans inventory what's installed on which machines, because installation is the footprint that matters.
- Entitlement reconciliation: Purchased entitlements, in all their metric complexity, matched against deployed installations to compute a compliance position.
- Audit defense: The core deliverable is an Effective License Position: proof, when the vendor's auditors arrive, that deployment doesn't exceed entitlement.
- Optimization within the entitlement: Re-harvesting installed licenses, restructuring agreements, and rightsizing at renewal, measured in on-prem terms.
Within this problem, mature SAM platforms in the Flexera and Snow class are excellent (we compare them in our guide to software asset management tools), and nothing in this article argues otherwise. If you run a significant Oracle, IBM, SAP, or Microsoft datacenter estate, this discipline is not optional and an SMP does not replace it.
What Broke
Then software stopped being installed, and four assumptions underneath SAM broke at once:
- There's nothing to scan. A SaaS application leaves no installation on any device and no footprint on any network. Discovery-by-scanning, SAM's foundational method, returns nothing. The signal moved to SSO logins, OAuth grants, finance transactions, and browser activity, sources classic SAM was never built to read.
- The license stopped being complex and started being perishable. A SaaS seat has almost no entitlement math: it's a per-user subscription. The hard problem shifted from interpreting the license to keeping it matched to reality, because the subscription bills again every month whether the seat is used, idle, or assigned to someone who left in October. SAM's superpower (entitlement reconciliation) addresses a problem SaaS mostly doesn't have, while SaaS's actual problem (continuous waste) needs per-user activity data SAM doesn't collect.
- Purchasing escaped procurement. Enterprise software arrived through a contract negotiation SAM could anchor to. SaaS arrives through a corporate card, a free tier that quietly converts, an OAuth grant with no invoice at all. A meaningful share of the estate now enters through doors no procurement-anchored system watches.
- The unit of management became the identity. An installed license attached to a device. A SaaS license is an account: a credential with access to data. That makes every unused SaaS seat two problems at once, recurring spend and an unattended door, and it means managing SaaS well is inseparable from managing the identities holding it, including non-human ones. SAM has no concept of an identity; it was never supposed to.
What an SMP Is
A SaaS management platform is what you get when you rebuild the SAM mission around those four new facts:
- Discovery from identity and financial signals rather than network scans: SSO and identity providers, direct app integrations, finance and expense systems, MDMs, CASBs, HRMS, directories, and browser extensions, because those are the places SaaS actually leaves footprints.
- Continuous license reconciliation rather than periodic compliance positions: purchased, assigned, and used tracked as live numbers per contract, with waste flagged on rolling windows and reclaimed while it's still cheap.
- Renewal and spend management as a first-class function, because in a subscription model, the renewal calendar isthe cost-control mechanism.
- Lifecycle automation tied to identity events: licenses granted by role at onboarding, adjusted at role changes, and reclaimed completely at offboarding, since HR events are where SaaS waste and SaaS risk are both born.
- Governance of the identity layer itself: who and what holds access, how it was granted, and whether it should still exist, extending to service accounts, tokens, and AI agents.
The Difference, Dimension by Dimension
When You Still Need Classic SAM
Being honest about this is the point of the article. Keep (or buy) a classic SAM capability if:
- You run a material Oracle, IBM, SAP, or Microsoft datacenter estate, where entitlement math and audit defense carry six- and seven-figure stakes.
- You hold perpetual licenses with complex terms (virtualization rights, downgrade rights, geographic restrictions) that require ongoing reconciliation.
- You face regular vendor audits and need a defensible Effective License Position on demand.
No SMP, ours included, replaces that discipline. An SMP pointed at an Oracle core-licensing problem is the wrong instrument, exactly as a network scanner pointed at SaaS sprawl is.
When the SMP Is the Answer
Buy an SMP as the system of record if:
- Your software estate is majority SaaS by app count (it almost certainly is; whether it is by spend is the better question to check).
- Your pain is sprawl, unknown apps, and renewal surprises rather than entitlement interpretation.
- Departed-employee accounts, orphaned seats, and shadow AI tools show up every time anyone looks.
- You want license management connected to onboarding, offboarding, and access governance rather than running as a standalone ledger.
And the Trap in the Middle
The expensive mistake isn't choosing the wrong category. It's assuming one covers the other.
Most legacy SAM suites now market a SaaS module, and the limitation is structural rather than cosmetic: a data model keyed to installations-on-devices has no natural place to put an identity, an OAuth grant, or a per-user activity stream. Retrofitting that is a rebuild, not a plugin, which is why SaaS modules on SAM suites tend to produce app lists without the usage, identity, and lifecycle depth the actual problem requires. The inverse trap is rarer but real: assuming an SMP's license tracking will survive an IBM audit. It won't, and it shouldn't claim to.
For most mid-size and larger organizations, the honest architecture is two layers with a clear boundary: classic SAM for the entitlement-heavy on-prem estate, an SMP for the SaaS and identity layer, and no illusions that either extends across the boundary.
Where Zluri Sits
We built Zluri as the second layer, deliberately and completely. Our SaaS management platform discovers the SaaS estate through eight methods against a 240,000+ app catalog, keeps purchased, assigned, and used reconciled per contract with projected cost and billed spend as separate figures, runs renewals as staged decisions routed to accountable owners, reclaims flagged waste through a consent-first workflow, and ties all of it to the identity lifecycle, so the seat and the account get handled in the same motion when someone joins, moves, or leaves.
We don't compute Oracle core positions, and we'd rather tell you that here than have you discover it in an evaluation. The full license mechanics are documented in how Zluri handles software license management, and the broader asset model in our guide to software asset management.
Frequently Asked Questions
Is an SMP just SAM for SaaS?
The mission is the same (know what you have, what it costs, whether it's compliant and used), but the engineering is different enough that the label misleads. SAM's methods (scanning, entitlement reconciliation, audit positioning) don't transfer to software that isn't installed, and an SMP's methods (identity-signal discovery, per-user activity, lifecycle automation) address problems SAM never had. Same question, rebuilt instrument.
Can a SAM tool with a SaaS module replace an SMP?
Usually not, for a structural reason: SAM data models key everything to installations on devices, while SaaS management keys to identities and their entitlements. A bolted-on SaaS module typically produces an application list, but not the per-user usage, OAuth visibility, and joiner-mover-leaver automation that make SaaS spend and risk actually controllable. If your SaaS estate is small, the module may suffice; if SaaS is the majority of your app count, it usually doesn't.
Do we need both a SAM tool and an SMP?
If you run a significant on-prem estate with complex enterprise licensing (Oracle, IBM, SAP, Microsoft datacenter), yes: classic SAM for that layer, an SMP for the SaaS and identity layer, with a clear boundary between them. If your estate is essentially all SaaS, a standalone SAM suite adds little, and the SMP is the system of record.
Where does license compliance sit in each model?
In SAM, compliance means deployment doesn't exceed entitlement, proven on demand to a vendor's auditors. In an SMP, the compliance surface shifts: staying within seat counts and contract terms, yes, but also the access side, demonstrating to your own auditors that seats, accounts, and entitlements belong to current, appropriate users. Different auditors, different evidence, same word.
Which one saves more money?
It depends entirely on where your spend sits. If most software spend is enterprise on-prem agreements, SAM-driven entitlement optimization and audit avoidance dominate. If most of it is subscriptions, the recoverable money is in idle seats, over-tiered users, unmanaged renewals, and departed-employee licenses, which is SMP territory. Check spend distribution first; the answer usually falls out of that number.
.svg)
