Admin and Privileged Access in SaaS

Ask who the administrators are in your twenty largest applications. Most organisations cannot answer without logging into each one.

Why it accumulates unmanaged

The person who set it up became the administrator, by default.

Administrators grant administrator to colleagues, for convenience.

Nobody removes it when the reason passes.

Administrator rights are frequently outside SSO, as a local account that survives directory deprovisioning.

Vendors grant it freely, because it reduces their support burden.

The result: a set of accounts with full control over company data, held by people nobody has listed, some of whom have left.

What administrator means in a SaaS application

More than people assume.

Access to all data in the application, typically, regardless of per-user permissions.

Ability to export everything.

Ability to change security settings, including disabling SSO enforcement or audit logging.

Ability to grant access, including to external parties.

Ability to configure integrations that move data elsewhere.

Ability to delete, sometimes irreversibly.

Building the list

Per application, extract the administrator list. Every major SaaS product exposes this in its admin console.

Record: application, administrator, account type, whether federated, when granted, and why.

Start with the applications holding your most sensitive data, and with the ones with the most users.

Expect surprises: former employees, vendors, consultants engaged years ago, and personal accounts.

Reducing it

A named administrator and a named deputy per application, and no more, is the target for most applications.

Remove everyone else, having confirmed what they need. Frequently they need an elevated user role rather than full administration.

Use role separation where the application supports it. Many have intermediate roles that cover the actual need.

Federate administrator accounts where possible, so deprovisioning reaches them.

Where a local administrator account is unavoidable — a break-glass account — document it, vault the credential, and monitor its use.

Vendor and consultant access

Frequently granted for an implementation and never revoked.

Audit specifically for external email domains in administrator lists. This is a five-minute check per application and it finds things.

Where ongoing vendor access is needed, grant it with an expiry, or grant it on request rather than permanently.

Monitoring

Alert on administrator role changes, in every application that supports it. Someone being granted administration should generate a notification to someone else.

Alert on security setting changes: SSO enforcement, audit log configuration, external sharing defaults.

Review the administrator list quarterly with the application owner.

Include administrator status in offboarding as an explicit check, since a departing administrator may hold a local account.

The break-glass question

Every application needs a route in if the normal one fails, which is what local administrator accounts exist for.

Document each one: which application, where the credential is held, who can retrieve it, and what the retrieval is logged to.

Rotate after use.

Review annually, because break-glass accounts accumulate and become ordinary accounts nobody remembers is privileged.

The first exercise

For an organisation that has never done this: take the ten applications holding the most sensitive data, extract the administrator lists, and read them.

That exercise takes a morning and it reliably finds at least one account that should not exist. It is the highest-yield security activity available from asset data.

The external domain check

A five-minute check per application that reliably finds access nobody intended to leave in place.

Export the user list and filter for email domains you do not own.

Consultants and implementation partners, frequently granted administrator rights years ago.

Vendor support accounts, created during onboarding.

Former employees using personal addresses, which happens where signup predated proper provisioning.

Partner organisations with legitimate access nobody has reviewed.

For each: confirm it is still needed, with a named internal sponsor, or remove it.

Repeat quarterly on the ten most sensitive applications. The first run finds things in almost every organisation.

Monitoring administrator changes

Administrator lists drift between reviews, and the drift is detectable in real time.

Alert on any administrator role grant, to someone other than the person granting it.

Alert on security configuration changes: SSO enforcement, audit logging, external sharing defaults, session policies.

Alert on organisation-wide OAuth grants.

Route the alerts somewhere they are read, which is the part that usually fails.

Review the alert volume monthly. A high volume means the administrator population is too large; a volume of zero usually means the alerting is not working rather than that nothing changed.