Most organisations cannot say how many SaaS applications they use, who has accounts in them, or which third-party apps hold OAuth grants into their core tenants, so leavers keep access and unknown integrations keep tokens. A SaaS management platform (SMP) builds that inventory and acts on it: it discovers applications, ties them to owners, contracts and licences, shows which users and which OAuth grants exist in each, and automates offboarding and licence reclamation. This vendor-neutral buyer's guide explains how to define requirements, which capability areas to test, the criteria and questions that separate strong products from dashboards, and how to run a proof of concept. It is for IT asset, identity and security teams evaluating a platform together. An SMP is not a SaaS security posture management tool: an SMP answers "what do we have, who uses it and what does it cost", while posture tools check the security configuration inside a small set of critical tenants. Many buyers need both, and the boundary is blurring, so test the capabilities you need rather than the label.
Key takeaways
- Discovery method decides coverage. Single sign-on logs only see sanctioned apps; finance data, browser telemetry, email metadata and OAuth grant APIs find the rest. Ask which methods a product uses and what each misses.
- OAuth grants are the security payload. A platform that lists apps but not the third-party integrations and scopes connected to your identity provider and collaboration tenants misses the riskiest non-human access.
- Offboarding is where value is proven. Measure how many apps outside single sign-on the platform can actually remove a leaver from, not how many it can display.
- Identity integration is not optional. The platform should read from your identity provider and HR source and hand access decisions to your identity governance process, not become a second, competing source of truth.
- The platform is itself a high-value target. It holds admin tokens to many SaaS tenants; judge its own access model as hard as its features.
Define requirements
- Problem statement: rank your drivers: unknown applications, licence spend, leaver access, audit findings on access reviews, or third-party OAuth risk. The ranking decides which capability area weighs most.
- Estate: approximate number of employees and contractors, the identity provider, the HR system of record, the main collaboration and email tenants, and whether devices are managed (browser telemetry needs managed browsers or endpoints).
- Ownership: who will run the platform day to day (IT asset management, identity, procurement or security) and who acts on findings. Unowned platforms become shelfware.
- Existing tools: whether identity governance, a CASB, a secure web gateway or a procurement suite already covers part of the job. Overlap is fine when it is deliberate.
- Privacy and works councils: browser and email based discovery inspect employee activity; involve privacy, legal and employee representatives before you choose a method, and record the lawful basis.
- Data residency: where usage data, user lists and tokens will be stored and processed.
Discovery techniques and triage are covered in depth in the Shadow SaaS and Unsanctioned App Discovery Guide; the leaver process in the SaaS Deprovisioning Guide guide.
Capability areas
| Capability area | What it does | What to look for |
|---|---|---|
| Discovery | Finds applications in use | Multiple methods (identity provider and SSO logs, OAuth grant APIs, finance and expense data, browser extension or endpoint agent, email metadata), each labelled in the results |
| Application inventory | One record per app with owner, department, contract, renewal and data classification | Deduplication of the same app found by several methods; workflow to assign and confirm owners |
| Account and user visibility | Lists who has an account in each app | Direct API connectors to major apps, with account status, last activity and admin flag; clear list of which apps have connectors |
| OAuth and integration visibility | Shows third-party apps and scopes granted into core tenants | Scope detail, granting user, grant date, last use, publisher verification; ability to flag or revoke |
| Licence and spend | Matches licences to usage and renewals | Inactive seat detection, renewal calendar, reclamation workflows |
| Lifecycle automation | Onboarding, mover and leaver actions across apps | Account removal through API, SCIM or ticketed manual tasks, with evidence of completion |
| Access reviews | Collects app owners' attestations | Reviews for apps outside identity governance, with results exported to it |
| Integration | Connects to the identity provider, HR, ITSM, SIEM and identity governance | Event and API outputs, not only CSV exports |
Evaluation criteria
| Criterion | Minimum acceptable | Strong |
|---|---|---|
| Discovery coverage | SSO logs plus finance data | Five or more methods, each result tagged with its source and first-seen date |
| Account visibility | Connectors to your top 20 apps | Connectors to most of your top 100, plus a documented way to load accounts for the rest |
| OAuth grant detail | App name and granting users | Scopes, grant and last-use dates, publisher status, revoke action with audit trail |
| Offboarding | Report of leaver accounts | Automated removal or suspension with verification, triggered by the HR or identity provider leaver event |
| Identity alignment | Reads users from the identity provider | Writes findings and review results to identity governance; never provisions outside agreed rules |
| Platform's own access | Admin token per connected app | Least-privilege, read-only scopes by default, write scopes only where actions are licensed, token inventory visible to you |
| Security of the vendor | Independent assurance report | Assurance report plus single sign-on and MFA for the console, role-based admin, customer-visible audit log, documented token storage |
| Privacy controls | Configurable data collection | Per-method opt-outs, data minimisation (domain only, no page content), regional hosting, retention settings |
Questions to ask vendors
- Which discovery methods do you use, and for each, what share of applications did it find in your last three deployments of our size?
- Show us an OAuth grant record: which scopes, which user granted it, when it was last used, and how we revoke it from your console.
- For a leaver, which apps can you remove the account from automatically, which only by ticket, and how do you prove removal happened?
- What scopes does your platform request in each connected tenant, which are write scopes, and can we run read-only?
- How are customer tokens stored and encrypted, who on your staff can access them, and how would we know if they were used?
- If your platform were breached, what could an attacker do in our tenants, and how fast could we revoke every grant you hold?
- How do you avoid becoming a second identity source that conflicts with our identity governance platform?
- What employee data does browser or email discovery collect, where is it stored, and for how long?
- How do you treat non-human accounts: service accounts, API keys and integration users inside SaaS apps?
- Which events can you stream to our SIEM, and in what format?
Red flags
- Write scopes by default: every connector asks for full admin rights, even for read-only discovery.
- Counts without evidence: large "apps discovered" figures with no source, first-seen date or deduplication.
- OAuth as a list of names: no scopes, no last-use date, no revoke action.
- Offboarding that only reports: leaver dashboards with no automated or tracked removal.
- No console audit log for customers: you cannot see what the platform's own admins or automations did in your tenants.
- Vague privacy answers: browser telemetry that captures full URLs or page content without a clear need.
- Provisioning outside policy: the platform creates accounts directly, bypassing approvals in identity governance.
Proof of concept
- Agree three to five success measures before starting, for example applications found that were not in your inventory, leaver accounts found in non-SSO apps, and OAuth grants with high-risk scopes.
- Connect read-only first: identity provider, one collaboration tenant and finance data. Record every scope each connector requests.
- Compare discovered applications with your current inventory and with procurement records; check a sample by hand for false positives.
- Pick ten recent leavers and check whether the platform finds their remaining accounts outside single sign-on.
- Review OAuth grants into your core tenants: confirm scope detail, revoke one test grant and confirm the audit trail on both sides.
- Run one automated offboarding on a test account across at least three apps, including one without SCIM.
- Have security review the vendor's token handling, console authentication and audit logging, and privacy review the data collected.
- At the end, disconnect and confirm that every grant and token the platform held has been revoked in your tenants.
Related evaluation pages: the SaaS Security Buyer's Guide for posture tooling, the IGA Buyer's Guide for governance, and the Consent Phishing and Illicit OAuth Grants Guide for why grant visibility matters. Supply chain incidents in 2025 showed that OAuth tokens held by one connected app can open hundreds of customer tenants, which is the same risk an SMP's own tokens carry.
How NHI Mgmt Group can help
We provide independent requirements and evaluation support for SaaS, identity and non-human identity programmes, including the OAuth grants, integration users and API keys that a SaaS management platform must find and the tokens it holds itself. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Shadow SaaS and Unsanctioned App Discovery Guide · SaaS Deprovisioning Guide · SaaS Security Guide · SCIM Provisioning Guide