Native SaaS admin centres show one tenant at a time, in each vendor's own terms, so posture across dozens of business-critical applications is hard to see and harder to keep from drifting. SaaS security posture management (SSPM) platforms connect to each application's admin APIs to check configuration, users, admin roles and third-party integrations against a policy set, and many now add threat detection on SaaS audit logs. The category overlaps with CASB and security service edge (SSE), identity threat detection and response (ITDR) and SaaS management or discovery tools, so the label tells you less than the coverage and the depth of checks. This vendor-neutral buyer's guide is for security architects, SaaS platform owners and identity teams writing requirements, running an RFP or deciding whether native tooling is enough. Our SaaS and OAuth App Governance Guide covers the integration risk in depth.
Key takeaways
- Decide which problem you are buying for. Posture and drift (SSPM), inline traffic and upload control (CASB or SSE), live account misuse (ITDR) and finding unknown apps (discovery) are different jobs; few products do all four well.
- Coverage is measured in checks, not logos. A connector that reads ten settings is not the same as one that reads three hundred. Ask for the check list for each of your tier 1 applications.
- Free baselines set the floor. CISA's ScubaGear and ScubaGoggles already test Microsoft 365 and Google Workspace against the SCuBA baselines; a paid platform must add breadth, drift history, remediation workflow or detection.
- The platform holds keys to every tenant. SSPM connectors need broad read access and sometimes write access across your SaaS estate. Score the vendor's protection of those tokens as hard as its features.
- Identity is most of the value. Admin roles, local accounts, MFA gaps, OAuth grants and connected apps are where SaaS breaches start, so test identity and integration visibility first.
Define requirements
Start from your estate, not the vendor's connector catalogue. Agree these points internally and put them in the RFP.
- Applications in scope: list tier 1 applications (identity provider, Microsoft 365 or Google Workspace, CRM, ITSM, code hosting, data warehouse, HR and finance) with tenant counts, including test and secondary tenants, and the licence tier of each, because API and log access often depend on it.
- Baselines to measure against: SCuBA policy IDs (for example MS.AAD.3.1v1, phishing-resistant MFA for all users), the CIS Microsoft 365 Foundations Benchmark, vendor hardening guides and your own policies. The CSA SaaS Security Capability Framework (SSCF) lists the customer-facing controls a SaaS product should expose and is a useful cross-check.
- Outcomes: posture reporting only, guided remediation, automated remediation, or detection and response. Each step needs more permissions and more trust.
- Operating model: who fixes findings (central security team or each app owner), which ticketing system receives them and which SIEM receives alerts.
- Data constraints: where configuration snapshots, user lists and log data will be stored, for how long, and which sub-processors handle them.
| Category | What it does | What it does not do | Choose it when |
|---|---|---|---|
| SSPM | API connection to each tenant; checks settings, roles, users and integrations against policy; tracks drift | Sees no traffic; limited to apps with a connector | You have several tier 1 apps and need continuous posture across them |
| CASB or SSE | Inline or log-based visibility of SaaS use; shadow SaaS discovery; session, upload and download controls | Little or no tenant configuration or SaaS-to-SaaS integration visibility | Shadow SaaS, unmanaged devices and data movement are the main concern |
| ITDR | Detects misuse of identities and sessions across IdP and SaaS logs | Usually shallow configuration checks | You need detection and response on accounts and tokens. See the ITDR Buyer's Guide |
| SaaS discovery or management | Finds apps from IdP, OAuth, browser and finance data; tracks owners, licences and renewals | Limited security depth | Inventory and ownership are the first gap |
| Native tools plus SCuBA | Admin centre posture scores and free baseline scanners | One tenant or vendor at a time; drift history and workflow are manual | Small estates centred on one productivity suite |
Size changes the answer. A 200-person company on one productivity suite with a CRM can often run ScubaGear or ScubaGoggles monthly, review OAuth grants quarterly and cover the CRM with its own health check. A large enterprise with dozens of tier 1 apps, several admin teams and regulators asking for evidence of continuous monitoring usually needs SSPM plus detection, and often SSE for discovery.
Evaluation criteria
Weight criteria to your requirements. An illustrative split is 25% coverage and depth, 25% identity and integration visibility, 15% remediation and drift, 15% detection, 20% platform security and everything else.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| App coverage and depth of checks | Connectors for all your tier 1 apps, with a published check list per app, and checks for new features within weeks of release | Large connector count but a handful of checks each; custom apps unsupported |
| Baseline mapping | Checks mapped to SCuBA policy IDs, CIS benchmark items and your own policies; mappings visible and editable | Proprietary "risk score" with no link to a named control |
| Identity visibility | Admins and privileged roles per app, local accounts that bypass SSO, MFA status, dormant and external users, guest accounts, and a cross-app view of one person's access | Relies only on IdP data; cannot see local accounts |
| OAuth and integration visibility | Inventory of connected apps, OAuth grants, scopes, integration users, API keys and Google Workspace domain-wide delegations, with last activity and owner | Lists app names without scopes or activity |
| Remediation and drift | Scheduled scans with history and diffs, exceptions with owner and expiry, tickets to app owners, optional one-click fixes with approval and rollback | Point-in-time reports; auto-remediation with no approval or audit trail |
| Threat detection on SaaS logs | Detections for new high-scope integrations, token use from new IPs, bulk export, new super admins and logging disabled; alerts to your SIEM | Detection depends on logs your licence tier does not produce, and the vendor does not say so |
| Data exposure | Public and "anyone" links, external sharing, public site guest access, sensitive data in shared files | Sharing checks only for one suite |
| Integrations and reporting | ITSM, SIEM and SOAR integrations, full API, framework and trend reporting | Data reachable only through the console |
| Platform security | SSO and enforced MFA for the console, customer-visible audit log, role-based access inside the tool, current independent assurance, named hosting regions | Shared admin accounts; no tenant audit log |
The platform's own tokens are high-privilege non-human identities
Posture tools need wide access to read configuration, and some APIs grant more than read. CISA's own assessment tool shows the scale: run unattended against Microsoft 365, ScubaGear needs Microsoft Graph application permissions including Directory.Read.All, Policy.Read.All and RoleManagement.Read.Directory, Exchange.ManageAsApp with the Global Reader role, and Sites.FullControl.All for SharePoint. CISA notes that some of these permissions include write privileges because of API limitations, and that ScubaGear "never uses these write privileges". A commercial SSPM covering twenty applications holds a similar set of credentials for each one. In Google Workspace, domain-wide delegation gives an app "access to the data belonging to all of your users", which is why Google recommends narrow scopes and regular review. If the SSPM vendor is breached, its stored tokens become an attacker's route into every customer tenant, the pattern seen in the Salesloft Drift breach, where stolen tokens from one chatbot integration opened hundreds of Salesforce tenants. Require read-only scopes by default, certificate or federated authentication instead of static secrets, IP restrictions on connectors, a separate and approved identity for any write-back, and an exportable connector inventory. See the NHI Security Platform Buyer's Guide.
Questions to ask vendors
- For each of our tier 1 applications, send the full list of checks, the APIs and permissions each connector requests, and which checks need a higher licence tier in the target app.
- How quickly do new checks appear after a vendor ships a feature, such as a new AI assistant or sharing option? Show the last three examples.
- Which checks map to SCuBA policy IDs and CIS benchmark items, and can we see and edit the mapping?
- How do you find local accounts that bypass SSO, and admins created directly in the application?
- Show the inventory of OAuth grants, connected apps, integration users and domain-wide delegations for one tenant, with scopes and last-used dates.
- Where are our tokens stored, how are they encrypted, who in your company can use them, and how would you tell us within hours if they were exposed?
- Can every connector run read-only? If remediation needs write access, can that use a separate identity we approve and can revoke independently?
- Which detections depend on premium log tiers, such as Microsoft Purview Audit (Premium) or Salesforce Event Monitoring?
- What does pricing count (users, applications, tenants or connectors), and what happens when we add an application or an acquisition?
- At contract end, how do we revoke every connector, and when is our data deleted?
Red flags
- Connectors that require a global or super administrator account, or a named person's credentials rather than a dedicated service identity.
- Claims of hundreds of supported apps with no per-app check list.
- No answer on how stored customer tokens are protected, or no history of security disclosures.
- Automated remediation without approval, change history or rollback.
- Posture scores that cannot be traced to a specific setting and baseline.
- Integration inventory that shows app names but not scopes, owners or activity.
- Detection claims that ignore what your licence tiers log.
Proof of concept
- Set the bar first: run ScubaGear or ScubaGoggles against your Microsoft 365 or Google Workspace tenant and record the results. A candidate must find at least as much, plus what the free tools cannot.
- Scope it: three to five tier 1 applications including one productivity suite, one CRM or ITSM and one niche application; include a test tenant.
- Connect with least privilege: create dedicated connector identities, record every permission requested, restrict by IP where possible and set an expiry date for the trial.
- Plant known issues: a local account that bypasses SSO, an admin without MFA, an "anyone" sharing link, a broad-scope OAuth grant, a dormant integration user and an extra super admin. Score detection rate and time to detect.
- Test drift and remediation: change a baseline setting and time the alert; run one guided fix and one automated fix in the test tenant, then roll it back.
- Test detection: simulate a bulk export and a new connected app approval, and confirm alerts reach your SIEM with enough context to act.
- Test the exit: revoke every connector credential, confirm access stops, and request written confirmation of data deletion.
Track a few numbers during the trial and after go-live: percentage of tier 1 apps covered, planted issues found, mean time to detect drift, high-severity findings open longer than 30 days, and percentage of integrations with a named owner.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: SaaS and OAuth App Governance Guide · ITDR Buyer's Guide · IVIP and ISPM Buyer's Guide · Third-Party Access Guide