Workday Integration System Users (ISU) Security Guide

Workday Integration System Users (ISUs) are some of the most privileged non-human identities in any organisation, because they read and write the HR record that drives every joiner, mover and leaver, yet they are usually exempt from password expiry, owned by nobody and shared with outside vendors. A payroll provider, benefits platform, identity provisioning tool or iPaaS connector that holds an ISU password or a non-expiring refresh token can see salaries, bank details and national identifiers, and in some cases change worker data that other systems trust. This guide goes deeper than the Workday Security Guide on one subject: the full lifecycle of ISUs and their OAuth API clients, from design and scoping through credential choice, rotation, monitoring and retirement when a vendor leaves. It is for Workday security administrators, HRIS integration teams and NHI programme owners. Workday's administrator documentation sits on Workday Community behind a customer login, so task names here come from Workday's public security page and from public integration guides by Microsoft and Workato; confirm them against your tenant's current release.

Key takeaways

One integration, one ISU, one security group. Workato's guidance is to limit each ISU to a single integration system; a shared ISU accumulates every domain any vendor ever needed and cannot be rotated without breaking something.
The security group is the real scope. An ISU's access is whatever its integration system security group holds in domain and business process policies, and a refresh token generated against the ISU inherits exactly that.
Vendor setup guides disagree. Microsoft's Entra tutorial selects "Do Not Allow UI Sessions"; Workato's tells you to leave it unchecked. Set your own baseline and make vendors justify exceptions.
Exempt from expiry means you own rotation. ISUs are commonly added to the password rules exemption for system users, so nothing forces a change; schedule rotation with the vendor or the password lives for years.
Retirement is where ISUs leak. When a pilot ends or a vendor is replaced, disable the ISU, revoke its API clients and refresh tokens, and remove it from its group the same day.

How identity and access work for ISUs

An ISU is a Workday account created with the Create Integration System User task for programmatic access. It is not a worker, so it does not appear in worker-based reviews, and it gets its access only through security groups.

Building block	What it does for an ISU	Setting to decide
Create Integration System User	Creates the account, user name and password	Naming convention (vendor, purpose, environment; Workato advises underscores or hyphens rather than spaces); "Require New Password at Next Sign In" unchecked; Session Timeout Minutes 0
Do Not Allow UI Sessions	Stops the credential being used to sign in to the Workday user interface	Select by default; record any vendor that needs it cleared
Maintain Password Rules	Lets administrators add ISUs to the list of system users exempt from password expiration	If exempted, set a rotation schedule outside Workday
Integration System Security Group (Constrained or Unconstrained)	Holds the ISU as its member; constrained groups need an organisation scope	Constrained whenever the integration serves part of the workforce
Maintain Domain Permissions for Security Group	Grants Get (read) and Put (write) on domains under Integration Permissions	Only the domains in the vendor's documented requirements
Edit Business Process Security Policy	Allows web service steps, for example Change Work Contact Information (Web Service) in Work Contact Change	Only for write-back integrations
Activate Pending Security Policy Changes	Makes changes live with an audit comment	Reference the change ticket in the comment

The integration connects through Workday Web Services (SOAP endpoints of the form /ccx/service/<tenant>/Human_Resources/v<version>), REST APIs, reports as a service, or file transfers. Workday's public security page states that it supports x509 certificate authentication for web services integrations, alongside WS-Security, and PGP encryption for file integrations.

Admin roles and privileged access over ISUs

Whoever can create ISUs, change their groups or generate their tokens controls the most sensitive data paths in the tenant. Treat these capabilities as privileged in their own right.

Creating ISUs and integration groups: limit Create Integration System User and Create Security Group to the integration security team. Every new ISU should have an approved request naming the owner, vendor and domains.
Changing domain permissions: an administrator who adds Put on a sensitive domain to an integration group has given a third party write access. Separate the person who edits from the person who runs Activate Pending Security Policy Changes where staffing allows, and review pending changes before activation.
Generating refresh tokens: Manage Refresh Tokens for Integrations creates a token against a named Workday account. Anyone who can run it for an ISU can mint a credential with that ISU's access. Restrict it as tightly as security policy editing.
Setting the ISU password: whoever sets or resets the password knows it. Generate it in a vault, set it in Workday and hand it to the vendor through the vault or a secure exchange, never by email or ticket.
Never use an administrator account: Microsoft's tutorial notes that using a Workday administrator account for the integration "may work fine for demos, but isn't recommended for production". Workato also warns against regular worker accounts, whose termination or profile changes break the integration.

See the Segregation of Duties Guide for separating HR, payroll and security administration.

Integrations, API tokens and service accounts

Scoping domains per integration type

Integration type	Typical domains (from public vendor guides)	Access	Scoping advice
Identity provisioning (read)	Worker Data: Workers, Worker Data: All Positions, Worker Data: Current Staffing Information, Worker Data: Business Title on Worker Profile	Get	Usually needs all workers, so Unconstrained is defensible; record why
Identity write-back	Person Data: Work Contact Information (email), Workday Accounts (user name), plus the Work Contact Change business process web service step	Put	Grant only the write-back you use; a separate ISU for write-back keeps read and write apart
Provisioning support domains	External Account Provisioning, Worker Data: Public Worker Reports	Put or Get as the vendor documents	Check whether your connector actually needs them
iPaaS and custom reports	Integration Process, Integration Debug, Worker Data: Current Staffing Information, Worker Data: Public Worker Reports, plus per-flow domains	Get, sometimes Put	The broadest risk: flows are added over time; review the group every quarter
Payroll, benefits, pension	Compensation, payroll, banking and dependant data	Get, sometimes Put	Constrained to the country, company or pay group served

A 403 response usually means the ISU lacks a domain. Fix it by adding the single missing domain to that integration's group, not by moving the ISU into a broader group.

Choosing a credential

ISU user name and password (Basic authentication): the most common and the weakest. The password usually sits in the vendor's system indefinitely. Use it only where the vendor offers nothing else, vault it and rotate it.
x509 certificate: supported for web services integrations. The private key stays with the integration, there is no shared password and the certificate expiry forces renewal. Use one certificate per integration and environment and track expiry in your certificate inventory.
OAuth 2.0 API client for integrations: created with Register API Client for Integrations and visible in the View API Clients report under API Clients for Integrations. Give it the minimum scopes (Workato documents the Integration scope as its minimum, plus operation-specific scopes). Selecting Non-Expiring Refresh Tokens turns the refresh token into a permanent credential; avoid it where the client can handle refresh.
File-based integrations: the ISU produces the file, but the credentials that matter are SFTP keys and PGP keys. Inventory them as NHI credentials with owners and expiry.

Decision guidance: prefer OAuth with expiring refresh tokens or x509 certificates for new integrations; accept Basic authentication only with documented rotation. For a small tenant with a handful of vendors, a spreadsheet inventory and annual rotation is a realistic start; large tenants with dozens of integrations need the ISU, API client and certificate inventory fed into the IGA or NHI platform and certified quarterly. See the SaaS API Token Security Guide.

Rotating ISU credentials without breaking payroll

Agree the window with the vendor and the integration owner, avoiding payroll cut-off and month end.
Generate the new password in your vault and share it through the vault or the vendor's secure credential portal.
Change the password in Workday and have the vendor update their side within the same window. Microsoft notes that its provisioning job goes into quarantine if the ISU password changes or the account is locked or expired, so watch for failed runs.
Run a test transaction (a read, or a write-back in a test worker in a sandbox first) and confirm the next scheduled run succeeds.
Roll back if the vendor cannot update in time by setting the previous password from the vault, then reschedule. Never leave the integration in a broken state over a payroll run.
Record the rotation date against the ISU in the inventory. For OAuth clients, regenerate the client secret and refresh token and revoke the old token; for certificates, issue the new one before the old one expires and remove the old one once traffic moves.

Retiring an ISU

Trigger: contract end, vendor replacement, pilot abandoned, or no successful activity for 90 days.
Steps: remove the ISU from its integration system security group and activate the change, disable or inactivate the account, revoke refresh tokens and delete the API client, remove certificates and SFTP keys, and ask the vendor to confirm deletion of stored credentials and data.
Why it matters: the Klue OAuth Breach began with a token created for a limited integration pilot that stayed active after the pilot was abandoned, with no owner to revoke it.

Logging and detection

Workday's public security page states that audit trails, user activity logs and sign-on reports are available, and that failed and successful logins and logouts are logged. Confirm user activity logging is enabled in tenant setup, then export ISU activity to the SIEM through a scheduled report or an integration that itself runs under a read-only ISU.

Detection	Source	ATT&CK
ISU sign-in to the user interface, or an ISU with "Do Not Allow UI Sessions" cleared	Sign-on reports; ISU configuration export	T1078.004 Cloud Accounts
ISU activity outside its schedule or from a new source	Sign-on reports and web service activity	T1550.001 Application Access Token
New API client or refresh token for an ISU	View API Clients report, audit trail	T1098.001 Additional Cloud Credentials
Domain or group added to an integration security group	Security policy activation history and audit comments	T1098.003 Additional Cloud Roles
Bulk report runs by an ISU beyond its normal volume	User activity logs	T1213 Data from Information Repositories
Writes to bank details or work contact data by a read-only integration	Business process history	T1199 Trusted Relationship

Repeated failed sign-ins for an ISU: usually a vendor still using an old password after rotation, but also a sign of guessing. Investigate both ways.
Metrics: percentage of ISUs with a named owner and vendor; ISUs with "Do Not Allow UI Sessions" selected; ISUs in Unconstrained groups (trending down); median age of ISU passwords and refresh tokens; API clients with non-expiring refresh tokens; ISUs with no activity in 90 days still enabled (target zero).

Hardening baseline

Inventory (weeks 1 to 2): export every ISU, its security groups, domains with Get or Put, API clients, refresh tokens, certificates and the vendor behind it. Mark ISUs with no identifiable owner.
Quick wins (weeks 2 to 3): select "Do Not Allow UI Sessions" on every ISU that does not need it, starting in a sandbox tenant to confirm nothing breaks; disable ISUs with no activity and no owner after a two-week warning to the business.
Split shared ISUs (weeks 3 to 8): create one ISU and one group per integration in a sandbox, run the integration end to end, then repeat in production. Roll back by restoring the old group membership, which is a single pending change.
Constrain: move payroll, benefits and regional integrations to constrained groups scoped to the organisations they serve.
Upgrade credentials: move integrations that support it to OAuth with expiring refresh tokens or x509 certificates.
Rotate and certify: rotate every ISU password, refresh token and secret on a schedule (for example every 6 to 12 months for Basic authentication, sooner after staff or vendor changes) and certify ISU groups quarterly through the access review process.

Common misconfigurations

Following each vendor's guide literally: one vendor's instructions leave UI sessions allowed, another adds broad domains for convenience, and the tenant ends up with the union of every vendor's defaults.
Unconstrained groups for regional vendors: a payroll provider for one country can read every worker worldwide.
Read and write in one ISU: a provisioning tool that only needs to read workers also holds Put on Work Contact Information, so a compromise lets the attacker change email addresses that drive account recovery elsewhere.
Non-expiring refresh tokens with no inventory: tokens minted during implementation stay valid long after the consultant has gone.
ISU passwords in tickets and emails: implementation projects share credentials informally and nobody rotates them at go-live.
No retirement trigger: integrations are switched off at the vendor end while the ISU, group and tokens stay active in Workday.

Framework mapping

Framework	Reference	ISU control
NIST SP 800-53 Rev. 5	AC-2 Account Management	ISU request, owner, review and retirement
NIST SP 800-53 Rev. 5	AC-3 Access Enforcement; AC-6 Least Privilege	Integration groups, constrained scope, minimal domains
NIST SP 800-53 Rev. 5	AC-5 Separation of Duties	Editing versus activating security policy; read versus write ISUs
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management	Password, certificate and refresh token rotation
NIST SP 800-53 Rev. 5	SA-9 External System Services; AU-6 Audit Record Review	Vendor integrations and ISU activity review
NIST CSF 2.0	PR.AA-01, PR.AA-05, GV.SC-07, DE.CM-03	Credentials, least privilege, supplier risk, monitoring
CIS Controls v8.1	Control 5 Account Management; Control 6 Access Control Management; Control 15 Service Provider Management	Service account inventory, scoped access, vendor oversight

Practitioner checklist

Inventory every ISU with owner, vendor, groups, domains, credentials and last activity.
Give each integration its own ISU and integration system security group; split read and write-back.
Select "Do Not Allow UI Sessions" by default and record any exception.
Use constrained groups wherever the integration serves part of the workforce.
Prefer x509 certificates or OAuth with expiring refresh tokens; avoid Non-Expiring Refresh Tokens.
Restrict who can create ISUs, edit integration groups and run Manage Refresh Tokens for Integrations.
Rotate ISU passwords and secrets on a schedule using a tested rotation runbook with rollback.
Retire ISUs, tokens and certificates the day an integration ends.
Send ISU sign-on and activity data to the SIEM and alert on UI sign-ins, new tokens and group changes.

Workday Integration System Users Guide: Scoping, Rotating and Retiring HR Integration Identities