SailPoint Hardening Guide: Securing the Identity Governance Platform

An identity governance platform holds the keys to every connected system, so a compromised SailPoint tenant is a compromise of the joiner, mover and leaver process itself. SailPoint Identity Security Cloud (parts of the current documentation also use the name SailPoint Human Fabric) aggregates accounts from sources, provisions access through connectors and runs certifications, which means its admins, API clients and Virtual Appliances carry write access into Active Directory, cloud platforms and business applications. This guide covers the SaaS tenant: user levels, MFA and network controls, personal access tokens and OAuth clients, Virtual Appliance deployment, audit events and a hardening baseline. It is written for IAM engineers, platform owners and security teams who run or audit the platform, and it uses only SailPoint's public documentation. IdentityIQ (the self-hosted product) is out of scope except where the principles carry over.

Key takeaways

• User levels are the tenant's privilege model. Admin (ORG_ADMIN) can do everything, so keep it to a small named group and use the narrower levels such as Source Admin, Role Admin and Certification Admin for daily work.
• API credentials inherit the creator's power. A personal access token can act with the rights of the user who made it, filtered by its scopes, and an omitted scope list means all scopes, so every token needs explicit scopes and an owner.
• Virtual Appliances hold connector credentials inside your network. Treat them as tier-zero servers: change the default password, restrict inbound SSH, block the cloud metadata address and keep the key passphrase in a vault.
• Network and session controls apply only to native sign-in. Network Definitions and Trusted Countries are not enforced for SSO users, so conditional access in your identity provider has to do that job.
• Vendor access is a setting you own. External Tenant Access controls when SailPoint staff and service accounts can reach your tenant, and it should be granted for a defined window and audited.

How identity and access work in SailPoint Identity Security Cloud

The tenant builds an identity for each person from an authoritative source (usually HR) through an identity profile, then correlates accounts aggregated from other sources to that identity. Access is granted through access profiles, roles and access requests, removed through lifecycle states and certifications, and pushed to targets by connectors. Most connectors for on-premises systems run on Virtual Appliances (VAs), which reach out to the SaaS tenant and hold the connection to each source.

Three separate access paths need hardening:

• Human administrators: users who sign in to the tenant UI, either through SSO from your identity provider or with native SailPoint credentials. Their user level decides what they can change.
• API clients: personal access tokens (PATs) and OAuth clients used by scripts, SIEM collectors, ITSM integrations and vendor integrations. They call https://[tenant].api.identitynow.com and request tokens from /oauth/token.
• Connector credentials: the service accounts each source connection uses to read and write accounts in the target system. These usually hold the widest rights in your estate, for example permission to reset passwords and change group membership in Active Directory.

An attacker who controls any of these paths can grant themselves access anywhere the platform provisions, and can make it look legitimate because the change arrives through the governance tool. That is why ATT&CK T1098 Account Manipulation and T1078 Valid Accounts are the techniques to plan against. See the IAM and IGA Basics.

Admin roles and privileged access

SailPoint assigns user levels to identities. The user level matrix lists what each level can do; the levels most relevant to hardening are below.

The matrix also lists combinations of levels that are incompatible. Use that list as your baseline segregation of duties rule set for the platform itself, and add your own rules, for example that no one should hold both Role Admin and Certification Admin. See the Segregation of Duties Guide.

Authentication for administrators

• MFA: users with access to the Admin menu (elevated users) are required to use MFA by default when they sign in with native credentials, with TOTP as one option. Users who sign in through your identity provider are not prompted by SailPoint, so the identity provider's MFA policy is the control that matters for them. Use phishing-resistant MFA there for anyone with an elevated user level.
• Emergency access admins: SailPoint documents emergency access administrators created through the IDN Administrator flat file source so that admins can sign in if SSO fails. These accounts bypass the identity provider and are prompted for SailPoint MFA. Keep two, store their credentials in a vault, alert on every sign-in, and never include or delete the slpt.support or slpt.services accounts, which SailPoint says must be left alone.
• Reset MFA: resetting another user's MFA is itself a takeover path. Restrict it, and log and review every use.
• Sessions: under Session Management the default maximum session is 12 hours (configurable up to 7 days) and the default idle timeout 15 minutes (up to 24 hours), with an option to end the session when the browser closes. Do not lengthen these for administrators.

Vendor access to your tenant

External Tenant Access lets you grant SailPoint access to your tenant for support and services, for a period of one week to one year (new tenants default to six months). Disabling it also disables PATs belonging to the slpt.services account. Grant it for a defined support window, record who approved it, and review the audit trail when it closes. The Okta support system breach shows why a provider's support path into a tenant deserves the same scrutiny as your own admins.

Integrations, API tokens and service accounts

API credentials are the non-human identities of the platform and the most common route for over-privilege. SailPoint supports two kinds, both managed under Admin > Global > Security Settings > API Management (PATs are also created from each user's own preferences).

Scopes decide the blast radius

The effective rights of a token are the intersection of its scopes and the user level of the identity behind it. The sp:scopes:all scope gives the full rights of that user level, sp:scopes:default gives a limited default set, and if you omit scopes when creating a token through the API the token receives all scopes. Fine-grained scopes separate read from manage (for example a read scope for identities versus a manage scope). Scope changes can take up to 30 minutes to apply, so plan revocations with that delay in mind.

• Owner and purpose: create integration PATs under a dedicated service identity with the lowest user level that works, not under a named admin who may leave. SailPoint's authorisation docs discuss this service account trade-off: the token survives staff changes, but the service identity must itself be governed.
• Least privilege: request read scopes only for collectors and reporting tools; never give a SIEM integration a manage scope.
• Expiry and rotation: keep the default six-month expiry or shorter, never leave it blank, and rotate on schedule. Org Admins can see all PATs, their last-used time and can delete them in bulk (up to 25 at a time); expired PATs can be restored within three months, so delete rather than let tokens lapse when an integration is retired.
• Storage: put secrets in a secrets manager on creation, never in scripts or tickets. See the API Key Management Guide.

Connector service accounts

Each source connection uses a service account in the target system. Give it only the rights the connector's features need (read-only for sources you aggregate but do not provision), set a source delete threshold so a bad aggregation cannot remove accounts in bulk, and govern these accounts in your PAM or secrets platform. See the Non-Human Identity (NHI) Guide.

Virtual Appliances

VAs make outbound-only connections to SailPoint and are patched by SailPoint, but you own their network placement and configuration:

• Network: inbound SSH (TCP 22) is the only inbound port and should be limited to internal admin hosts. Outbound needs DNS (53), NTP (123) and HTTPS (443) to an allow-list of SailPoint domains. Do not place VAs in a DMZ. If you inspect TLS, the VA has to trust your private root CA.
• Host: change the default sailpoint user password at first boot, block the cloud instance metadata address 169.254.169.254 when running in a public cloud, and use TLS for every connection to sources.
• Keys: the keyPassphrase protects stored credentials and must be identical on every VA in a cluster; keep it in a vault. FIPS mode can be enabled but is irreversible, so test it first.
• Resilience: run at least two VAs per cluster and keep production and sandbox clusters separate.

Logging and detection

Every admin action, configuration change and API call is recorded as an audit event in the tenant's search index. You can query it in the UI (Search, events) or with the Search API against the events index and forward it to your SIEM with a read-scoped token. SailPoint publishes an audit events reference; its documentation notes the event list is not comprehensive, so validate the events you depend on in a sandbox.

Metrics that show the controls work:

• Number of identities with Admin user level (target: a small fixed number, with a named owner each).
• Percentage of PATs and OAuth clients with an expiry, an owner and explicit scopes (target: 100%).
• Tokens unused for 90 days (target: zero, deleted rather than left to expire).
• Days External Tenant Access was open this quarter, against approved support tickets.
• Mean time from a source or user level change to SIEM alert review.

Hardening baseline

Roll the baseline out in phases. Test each change in a sandbox tenant first, because network restrictions and scope changes can lock out admins or break integrations.

1. Inventory: export every identity with an elevated user level, every PAT and OAuth client (owner, scopes, last used, expiry), every source and its connector account, and every VA cluster.
2. Admin access: move all admins to SSO with phishing-resistant MFA in the identity provider, reduce Admin to a small group, reassign others to narrower levels, set up two vaulted emergency access admins and alert on their use.
3. Sessions and network: keep the default 12-hour maximum and 15-minute idle session, enable end-on-browser-close, and for native sign-ins define a Network Definition (CIDR) and Trusted Countries. Create the Network Definition before enabling Block Access From Off Network, or everyone using native sign-in is blocked.
4. API credentials: set explicit least-privilege scopes, expiry of six months or less, a service identity owner and vault storage for each token; delete unused ones.
5. Virtual Appliances: confirm the default password is changed, SSH is restricted, metadata access is blocked, the passphrase is vaulted and clusters have two VAs.
6. Connectors: review each connector account's rights against the features used and set delete thresholds on authoritative and high-impact sources.
7. Monitoring: forward audit events to the SIEM and build alerts for the events in the table above.
8. Vendor access: close External Tenant Access outside approved support windows.

Rollback: keep an emergency access admin able to sign in before tightening network rules, record previous scope sets before changing them, and remember scope changes take up to 30 minutes to apply.

Decision guidance

• PAT or OAuth client: use a PAT under a dedicated service identity for simple server-side collectors; use an OAuth client with authorisation code when a tool must act as the signed-in user, so actions are attributed to a person.
• SSO or native sign-in for admins: SSO lets you apply device and location policy centrally, but it moves MFA enforcement out of SailPoint; native sign-in keeps SailPoint MFA and network controls but adds another credential to manage. Most organisations use SSO for all admins plus vaulted emergency accounts.
• Small versus large estates: a small team may have only two or three admins, in which case compensating controls (alerts on every user level change, monthly review by someone outside the team) replace strict separation. Large estates should use sub-admin levels and governance groups to split source and role administration by business unit.

Common misconfigurations

• Admin as the default level for the IAM team: everyone who touches the tenant gets ORG_ADMIN, which removes any separation between building roles and certifying them.
• Tokens created with no scopes: creating a PAT through the API without scopes grants all scopes, so a SIEM collector ends up able to change identities.
• Tokens tied to leavers or with no expiry: blank expiry dates and PATs owned by staff who have moved on. The Cloudflare breach shows how credentials missed in one rotation exercise give an attacker a way back in.
• Relying on SailPoint network rules for SSO users: Network Definitions and Trusted Countries do not apply to SSO sign-ins, so the identity provider must enforce location and device policy.
• VA left on defaults: default password unchanged, SSH open to the whole network, or VAs placed in a DMZ.
• Over-privileged connector accounts: a domain admin used for an AD source that only needs to manage specific OUs.

Framework mapping

Practitioner checklist

• Admin (ORG_ADMIN) held by a small named group; everyone else on the narrowest user level, checked against SailPoint's incompatible combinations.
• All admins sign in through SSO with phishing-resistant MFA; two vaulted emergency access admins with sign-in alerts.
• Session Management at or below the 12-hour maximum and 15-minute idle defaults.
• Every PAT and OAuth client has explicit scopes, an owner, an expiry of six months or less, and its secret in a vault.
• Unused tokens deleted; PAT list reviewed monthly using last-used dates.
• VAs: default password changed, SSH limited to admin hosts, metadata address blocked, passphrase vaulted, two per cluster.
• Connector accounts limited to required rights; delete thresholds set on high-impact sources.
• Audit events forwarded to the SIEM with alerts on source, identity profile, user level and token changes.
• External Tenant Access open only for approved support windows.
• The platform's own admins and tokens included in your access review campaigns. See the Access Reviews Guide.

Standards and references

• SailPoint: User Level Matrix
• SailPoint Developer Community: Authentication
• SailPoint Developer Community: Authorization
• SailPoint: Managing API Keys and Personal Access Tokens
• SailPoint: Virtual Appliance Requirements
• SailPoint: Restricting Access by Network and Geography
• SailPoint: Audit Events
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: IGA Buyer's Guide · Joiner-Mover-Leaver Guide · Okta Security Hardening Guide · BeyondTrust Hardening Guide