Every business SaaS application has its own super admins, and most organisations protect the identity provider's administrators carefully while leaving the owners of their code, CRM, ticketing and chat platforms with ordinary accounts, standing rights and nobody watching. An attacker who becomes an organisation owner in a source code platform, a system administrator in a CRM or an org owner in a chat platform can export data, add integrations, disable logging and create backdoor accounts without touching the identity provider again. This guide is a cross app playbook for the admin accounts of business applications: how to inventory them, enforce phishing-resistant authentication, restrict where they sign in from, separate admin identities, delegate with narrower roles and alert on admin changes. It uses Atlassian Cloud, GitHub, Salesforce, ServiceNow and Slack as worked examples, listed alphabetically; the order is not a ranking. Identity provider and cloud console super admins are covered in the Admin panels and super admin accounts guide, and emergency accounts in the Break-Glass Account Guide.
Key takeaways
- Each app has its own top role. Atlassian organization admin, GitHub organization owner, Salesforce System Administrator, ServiceNow admin and Slack Primary Owner and Org Owners each control the whole tenant independently of the identity provider.
- Small, never one. GitHub's documentation says to keep the owner role limited but to no fewer than two people; the same rule fits every app, so one departure or lockout does not strand the tenant.
- Delegate with narrower roles. Every example app offers roles below the top one, such as Atlassian user access and app admins, GitHub security managers, Slack system roles and ServiceNow elevated roles. Most admin work does not need owner rights.
- Network restrictions have gaps. Atlassian IP allowlists do not cover admin.atlassian.com, and Salesforce trusted IP ranges only skip verification while profile login IP ranges block. Read what each control actually restricts.
- Admin audit logs must leave the app. Retention is limited (GitHub keeps 180 days of organisation audit log; Salesforce login history covers six months), so forward admin events to your SIEM.
How identity and access work for SaaS admins
In most business applications an administrator is a normal user account with an extra role. If the app is connected to single sign-on, the admin signs in through the identity provider (IdP) like everyone else, and the app grants the role locally. That creates three exposures that IdP controls do not reach on their own:
- Local fallback logins: many apps keep a local password path for owners or administrators so they can fix a broken SSO configuration. That path bypasses IdP conditional access and MFA policy unless it is separately protected.
- Locally granted roles: the admin role usually lives in the app, not in the IdP group, so a compromised admin can create new admins inside the app that never appear in IdP reviews.
- Non-interactive access: admins create API tokens, personal access tokens and OAuth grants that carry their privileges and are not stopped by IdP session controls.
The protection model is therefore layered: strong authentication at the IdP, the app configured so SSO is the only interactive route for admins, the admin role assigned from a governed source, and the app's own audit log watched for role and policy changes. See the Privileged Access Management Guide for the wider model and the Phishing-Resistant MFA Guide for authenticator choice.
Admin roles and privileged access
Start with an inventory: for every sanctioned SaaS app, list the top admin role, who holds it, whether the account is a dedicated admin identity, and how the role was granted. The table gives the starting point for the five example apps, from each vendor's documentation.
| App | Top admin roles | Narrower roles for delegation | Notes from vendor documentation |
|---|---|---|---|
| Atlassian Cloud | Organization admin | Unit admin, site admin, user access admin, app admin | Organization admins manage users, groups, apps, SSO and SAML, provisioning, passwords and two-step verification, security settings, API keys and the audit log, and can create other organization admins. |
| GitHub | Organization owner (and enterprise owner on Enterprise Cloud) | Security manager, billing manager, GitHub App manager, moderator | Owners have complete administrative access. GitHub advises keeping the role limited but to no fewer than two people. Security managers can view alerts, manage security settings and read all repositories. |
| Salesforce | System Administrator profile and users with powerful permissions such as Modify All Data | Custom profiles and permission sets with only the setup permissions required | Profile Login IP Ranges deny logins from any other address; Setup Audit Trail logs configuration changes. |
| ServiceNow | admin role, with security_admin as an elevated role | Scoped admin roles such as user_admin; elevated roles that must be activated per session | Only users with admin can grant admin. In the base system security_admin is the only elevated role; elevation lasts for the current session only and must be selected manually. |
| Slack | Primary Owner and Owners (workspace); Org Primary Owner and Org Owners (Enterprise) | Admins and Org Admins; system roles such as Users Admin, Security Admin, Channels Admin, Audit Logs Admin and Integrations Admin | Only the Primary Owner can delete the workspace or transfer ownership. Admins cannot reach billing. |
Availability: Atlassian unit admins and centralised user management depend on the organisation's admin experience. GitHub enterprise owner and enterprise level controls require GitHub Enterprise Cloud. Salesforce Shield adds Event Monitoring and longer audit retention. ServiceNow High Security Settings are active by default on new instances. Slack org roles and custom roles are Enterprise only, and system roles need Business+ (limited set) or Enterprise.
- Separate admin identities: give each top role holder a dedicated admin account in the IdP, without a mailbox where possible, used only for administration. The daily account that reads email and browses the web should not hold owner rights.
- Count and justify: aim for two to four holders of each top role, each named and approved, and move everyone else to a narrower role.
- Elevate rather than stand: where the app supports per session elevation (ServiceNow elevated roles) or the IdP can assign the admin group just in time, use it so the top role is held only while needed.
- Govern the grant path: assign admin roles from IdP groups or SCIM where the app supports it, and treat any admin created directly in the app as an exception to investigate.
Authentication and sign-in restrictions
For admin accounts, the target is phishing-resistant MFA (FIDO2 security keys or passkeys) enforced at the IdP, with SSO enforced in the app so there is no weaker path. Where an app keeps its own second factor, configure it to allow only strong methods. GitHub, for example, lets owners require two-factor authentication and select "Only allow secure two-factor methods", which blocks users who still have SMS configured; members without compliant 2FA lose access to organisation resources, and outside collaborators are removed.
| Control | What to set | Caveat to check |
|---|---|---|
| SSO enforcement | Require SSO for all users, including admins, and keep at most one documented local fallback account | Fallback accounts need their own strong MFA and alerting; see the break-glass guide |
| App native MFA | Strong methods only; SMS disabled | Check whether the policy applies to owners and to service users |
| IP or network restriction | Restrict admin sign-in to corporate egress, a privileged access workstation network or a VPN | Atlassian IP allowlists cover Jira, Confluence and their admin areas, but admin.atlassian.com stays reachable from outside the list. GitHub IP allow lists also restrict PATs, SSH keys and app tokens, and cannot be used with Codespaces. Salesforce trusted IP ranges do not block; profile Login IP Ranges do. |
| Device restriction | Require a managed, compliant device for admin sessions through IdP conditional access | Only effective if the app forces SSO |
| Session lifetime | Shorter sessions for admin identities | Slack sets session duration for desktop and mobile separately; Enterprise admins can vary it for specific members through admin.users.session.setSettings |
Help desk resets are the weak point most attackers aim for. Require in-person or strongly verified identity checks before resetting MFA for any admin identity, and alert when it happens. See the Okta Security Hardening Guide for IdP side controls.
Integrations, API tokens and service accounts
Admin rights leak into non-human identities. An owner who creates a personal access token, installs an OAuth app or authorises an integration often gives it the owner's full reach, and that access outlives the admin's session and sometimes the admin's employment.
- Admin owned tokens: inventory tokens and keys created by admin accounts (Atlassian API tokens, GitHub personal access tokens, Slack user tokens, Salesforce connected app sessions, ServiceNow integration users) and replace them with scoped service identities where possible.
- Integration install rights: restrict who can approve third party apps. Slack has an Integrations Admin system role, GitHub separates GitHub App managers from owners, and Atlassian app admins can add only free Marketplace apps that do not act on a user's behalf.
- Integration users with admin rights: integration and service accounts are frequently given the top role for convenience. Give them the narrowest role and IP restrictions where the platform allows.
- Incidents to learn from: the ShinyHunters Salesforce Data Theft Campaign 2025 used phone calls to persuade staff to authorise malicious connected apps, and the Salesloft Drift Breach 2025 showed how one integration's OAuth tokens opened hundreds of tenants.
See the SaaS API Token Security Guide and the SaaS and OAuth App Governance Guide.
Logging and detection
Each app keeps its own admin audit trail, with its own retention and access rules. Collect them centrally before you need them.
| App | Admin audit source | Retention and access notes |
|---|---|---|
| Atlassian Cloud | Organisation audit log in Atlassian Administration | Viewable by organization, unit and site admins for their scope |
| GitHub | Organisation audit log (categories include org, personal_access_token and oauth_application) | Last 180 days; only owners can access it; default view shows three months |
| Salesforce | Setup Audit Trail, Login History, Event Monitoring | Login History covers six months; Event Monitoring and longer retention come with Shield |
| ServiceNow | System logs and audit history of role and ACL changes | Changes to ACLs and High Security Settings require security_admin elevation, which makes elevation events a useful signal |
| Slack | Audit Logs API (auditlogs:read scope) | Enterprise plans; must be installed at organisation level by the Enterprise organisation Owner |
Alert on these events in every app:
- A user granted the top admin role, or the count of top role holders changes.
- SSO, MFA or IP restriction settings changed or disabled.
- Audit log streaming or retention changed.
- A new integration, OAuth app or token created by an admin account.
- Bulk export or data download by an admin, and admin sign-in from a new country, network or device.
- Elevation to a privileged role outside a change window.
Metrics: top role holders per app against target; percentage of admin identities that are dedicated accounts; percentage of admins covered by phishing-resistant MFA through enforced SSO; admin audit logs forwarded to the SIEM by app; median time to review an admin grant alert. See the SaaS Audit Log Retention and Licensing Guide.
Hardening baseline
- Inventory (week one): list every sanctioned app, its top role, holders and grant path. Use the SaaS management platform or IdP app catalogue as a starting list and add apps outside SSO from finance records. See the Shadow SaaS and Unsanctioned App Discovery Guide.
- Reduce: cut top role holders to two to four per app and move the rest to narrower roles. Expect pushback from people who use owner rights for routine tasks; find them a narrower role first.
- Separate: issue dedicated admin identities, enrol them with security keys or passkeys, and move top roles onto them.
- Enforce: require SSO, restrict admin sign-in by network or device where supported, and limit native MFA to strong methods. Pilot with one app and keep the documented fallback account tested.
- Monitor: stream audit logs and switch on the alerts above.
- Review: quarterly access review of every top role, signed by the app owner, plus a check for admins created outside the governed grant path.
Rollback: before enforcing SSO or IP restrictions, confirm a working fallback admin from an allowed location and document how to revert the setting. A misconfigured allowlist can lock every admin out.
Small versus large organisations: a small team may have the same two people as owners of every app; give them separate admin identities with security keys and forward logs even if nobody else administers anything. Large organisations should map app admin roles to tiers, govern them in the identity governance platform and alert in the SOC. CISA's SCuBA project publishes secure configuration baselines for Microsoft 365 services that are a useful model for the format of an app baseline. See the CISA SCuBA Baselines Guide.
Common misconfigurations
- Everyone in IT is an owner: top roles granted for convenience years ago, never reviewed, including leavers and contractors.
- Admin on the daily account: the owner of the source code platform reads email and approves OAuth prompts with the same identity.
- Local login left open: SSO is configured, but admins can still use a password and weak second factor directly on the app.
- Allowlist assumed complete: an IP allowlist is in place, but the admin hub, certain integration types or a different product in the same tenant sit outside it.
- Logs left in the app: audit history ages out after six months or 180 days and the incident is discovered later.
- Integration users with the top role: a sync account holds full admin and its credential sits in a script.
Practitioner checklist
- Inventory the top admin role and its holders in every sanctioned SaaS app, with grant path and owner.
- Keep two to four holders of each top role and move everyone else to the narrowest role that works.
- Issue dedicated admin identities enrolled with security keys or passkeys, separate from daily accounts.
- Enforce SSO for admins and restrict any local fallback login to one tested, monitored account.
- Apply network or device restrictions to admin sign-in, and document what each restriction does not cover.
- Restrict who can install integrations and replace admin owned tokens with scoped service identities.
- Forward every app's admin audit log to the SIEM and alert on role grants and security setting changes.
- Require strong identity verification before help desk MFA resets for admin identities.
- Review top role holders quarterly with the app owner's sign-off.
Standards and references
- Atlassian: What are the different types of admin roles?
- GitHub Docs: Roles in an organization
- Salesforce Help: Restrict where and when users can log in
- ServiceNow: Elevated privilege roles
- Slack: Types of roles in Slack
- CISA: Secure Cloud Business Applications (SCuBA) Project
Related NHI Mgmt Group resources: Atlassian Cloud Security Guide · GitHub and GitHub Actions Security Guide · Salesforce Security Guide · ServiceNow Security Guide · Slack Enterprise Security Guide