Integration Monitoring for Enterprise: SSO and Access Control
What to require from a monitoring vendor on identity, and the offboarding gap that leaves live tokens behind a revoked account.
At enterprise scale the monitoring question shifts from whether failures are detected to who is allowed to see them, who can change them, and what happens to both when somebody leaves.
This page is a requirements checklist you can take to any vendor, including us. Where a capability is not standard, it is better to establish that during evaluation than during an audit.
What to actually require on identity
| Requirement | Why it matters | Common vendor gap |
|---|---|---|
| SAML or OIDC SSO | Access follows your directory | Often gated to the top tier |
| SCIM provisioning | Accounts created from the directory | Frequently absent entirely |
| SCIM deprovisioning | Access removed on offboarding | The most common gap |
| Enforced SSO | Blocks password fallback | Supported but off by default |
| Role-based permissions | Read-only vs configure vs admin | Often just admin and member |
| Scoped API tokens | Automation without admin rights | Tokens inherit full user rights |
Deprovisioning is the row to press hardest on. SSO controls whether somebody can log in today; SCIM deprovisioning is what removes them when they leave. A vendor with SSO and no SCIM leaves dormant accounts that reactivate if directory access is ever restored.
Ask specifically whether disabling a user in the directory revokes their existing API tokens. The answer is frequently no, and a personal API token outlives the account that created it.
Two follow-up questions are worth asking in the same breath: does the vendor support SAML 2.0 as well as OIDC, and what is the maximum session lifetime you can enforce. A tool that allows an indefinite session has effectively opted out of your directory's controls after first login.
The offboarding gap nobody closes
This is worth separating out because it sits between two teams and therefore belongs to neither.
When an employee leaves, IT revokes their accounts. What IT does not do is enumerate the third-party integrations that employee authorised on behalf of the company: the Google Workspace connection, the Stripe access, the OAuth grants to a dozen SaaS tools.
Those tokens either keep working, which is a security problem, or stop working, which is an availability problem. Both are worse than knowing which ones exist.
The fix is a policy that integrations are authorised through service accounts, plus an inventory of the ones that predate the policy. The inventory is the harder half and it is the one that pays off.
Least privilege for monitoring itself
Monitoring tools accumulate access quietly. A tool that started with read access to one endpoint ends up holding credentials for a dozen systems because each integration was convenient at the time.
Keep the monitoring surface minimal by design. A heartbeat receiver needs no access to your systems at all, because the direction is inbound: your job calls the monitor. Anything that requires you to hand over credentials to be polled deserves more scrutiny than anything that does not.
That distinction is worth raising in a security review, because it changes what the vendor could do with a breach of their own systems.
Where SensaCat currently stands
Being direct rather than aspirational: SSO is available on the Enterprise tier, and granular role-based access control is on the roadmap rather than shipped. Today the model is account membership with a small number of roles.
If enforced SSO with SCIM deprovisioning and fine-grained roles is a procurement requirement, evaluate accordingly and ask us where we are rather than assuming. We would rather lose an evaluation than be discovered mid-implementation.
For the audit and retention side of enterprise requirements, see integration monitoring for regulated industries.