Workday Security Guide: Security Groups, Integrations and Tenant Hardening

A Workday tenant holds salaries, bank details, national identifiers and the hire and termination events that drive every downstream account, so a single over-scoped security group or integration user can expose the whole workforce or create accounts elsewhere. Workday's configurable security model is powerful and also easy to get wrong, because access is granted by combining security groups, domain security policies and business process policies, and integrations run as Integration System Users that rarely receive the scrutiny people get. This guide explains how identity and access work in Workday, how to control security administrators, how to secure integration accounts and OAuth API clients, what to log and how to harden a tenant. It is written for Workday security administrators, HRIS and integration teams, and identity and security engineers. Workday's detailed administrator documentation sits on Workday Community behind a customer login; this guide uses Workday's public security pages and public integration documentation from identity vendors, and task names should be checked against your tenant's release.

Key takeaways

• Access is a combination, not a role. A user's effective access is the set of security groups they belong to, multiplied by the domain and business process security policies that grant those groups permissions, so reviews must look at policies as well as memberships.
• Integration System Users are the main non-human identities. Each integration should have its own ISU, in its own integration system security group, with only the Get and Put domains it needs and "Do Not Allow UI Sessions" selected.
• Nothing changes until it is activated. Security policy edits stay pending until someone runs Activate Pending Security Policy Changes with an audit comment, which gives you a natural change-control and evidence point.
• OAuth API clients can hold non-expiring refresh tokens. "Register API Client for Integrations" offers a Non-Expiring Refresh Tokens option, which turns a refresh token into a permanent credential to vault, inventory and rotate.
• SSO has a back door you must manage. The login.flex?redirect=n URL lets users fall back to a Workday username and password when SSO is broken, so native passwords must be restricted to break-glass accounts.

How identity and access work in Workday

Workday authenticates people with native Workday passwords, SAML single sign-on or OpenID Connect, and supports X.509 certificate authentication for users and web services integrations, according to Workday's public security page. Identities can be created in Workday or integrated from directories such as Active Directory. Security is role-based and configurable: administrators use roles, security groups and business process configurations to control which data users can see and which actions they can take.

The building blocks

• Security groups: collections of users or roles. Common types include user-based groups (people assigned directly, typical for administrators), role-based groups (people holding a role on an organisation, such as HR Partner for a supervisory organisation, either constrained to that organisation or unconstrained), job-based groups, membership-based groups and integration system security groups. Intersection and aggregation groups combine others.
• Constrained versus unconstrained: an unconstrained group gives its members access to all data instances the group secures; a constrained group gives contextual access to a subset, scoped by organisation.
• Domain security policies: each functional area of data (for example Worker Data: Workers, Worker Data: Current Staffing Information, Person Data: Work Contact Information) is a domain. Policies grant groups View or Modify access for people in the UI and Get or Put access for integrations.
• Business process security policies: control who may initiate, approve or act on steps in processes such as Hire, Terminate or Work Contact Change, including web service steps such as Change Work Contact Information (Web Service).
• Activation: policy edits are pending until activated with Activate Pending Security Policy Changes, which records an audit comment.

Why HR data is different

Workday is usually the authoritative source for joiner, mover and leaver events. An identity platform reads workers from Workday and creates, changes or disables accounts in the directory, and some connectors write email addresses and usernames back. Anyone who can change worker data or business process outcomes in Workday can therefore influence access everywhere else. See the Joiner-Mover-Leaver Guide and the SCIM Provisioning Guide.

Admin roles and privileged access

Workday has no single "admin" switch. Privilege comes from membership of groups that hold Modify on security configuration domains, or that can run security tasks such as Create Security Group, Maintain Domain Permissions for Security Group, Edit Business Process Security Policy, Edit Tenant Setup, Security and Activate Pending Security Policy Changes. Treat every group with those permissions as a privileged group.

• Segregation of duties: HR, payroll and security administration should not sit in one person. A person who can both change bank details and approve the change, or both grant themselves a group and activate it, is a fraud risk. See the Segregation of Duties Guide.
• Help desk and social engineering: attackers who call the help desk to reset an administrator's MFA, or who talk staff into approving access, bypass every policy above. The same pattern of phone-based pretexting emptied CRM tenants in the ShinyHunters Salesforce campaign of 2025. See the Account Recovery and Help Desk Security Guide.
• Authentication for administrators: require SSO with phishing-resistant MFA at the identity provider for every member of a privileged group, and use Workday authentication policies to stop privileged groups signing in with a native password.
• Break-glass: keep one or two native-login accounts for SSO failure, with vaulted passwords and an alert on every sign-in. See the Break-Glass Account Guide.

Integrations, API tokens and service accounts

Workday integrations, from payroll vendors and benefits providers to identity platforms, connect through SOAP web services (Workday Web Services, for example under /ccx/service/<tenant>/Human_Resources/v<version>), REST APIs and file-based exports. Each runs under an identity that can read, and often write, workforce data.

Integration System Users

1. Create one ISU per integration with the Create Integration System User task. Shared ISUs make it impossible to scope, rotate or attribute activity.
2. Select "Do Not Allow UI Sessions" so the password cannot be used to sign in to the Workday interface. Microsoft's Entra provisioning tutorial recommends this; some integration vendors' instructions leave it unchecked, so check each vendor's guide against this baseline.
3. Session and password settings: integration tutorials set Session Timeout Minutes to 0 and exempt the ISU from password expiry under Maintain Password Rules. An exemption from expiry means rotation must be scheduled by you, not forced by the tenant.
4. Create a dedicated integration system security group with Create Security Group, choosing Integration System Security Group (Constrained) where the integration only needs part of the organisation, and Unconstrained only where it must see every worker.
5. Grant only the domains needed with Maintain Domain Permissions for Security Group. Microsoft's tutorial, for example, grants Get on Worker Data: Workers, Worker Data: All Positions, Worker Data: Current Staffing Information and Worker Data: Business Title on Worker Profile, and Put on Person Data: Work Contact Information or Workday Accounts only if email or username write-back is used.
6. Activate and record with Activate Pending Security Policy Changes, and keep the audit comment as change evidence.

Microsoft's tutorial also warns that using a Workday administrator account for an integration is not recommended for production. It is still a common shortcut in implementations.

Integration credential types

OAuth API clients

• Registration: "Register API Client for Integrations" creates a client ID and secret and lets the administrator choose scopes and the Non-Expiring Refresh Tokens option.
• Refresh tokens: generated with "Manage Refresh Tokens for Integrations" against a named Workday account, often an ISU. The token inherits that account's access, so the account's security groups are the real scope.
• Inventory: the View API Clients report lists clients, with an API Clients for Integrations tab and the token and authorisation endpoints. Review it quarterly and revoke clients without an owner.
• AI agents and new connectors: AI assistants, agent platforms and Model Context Protocol tools that query HR data should get the same treatment: a dedicated account, a constrained group, read-only domains and logged activity. See the Identity Governance for AI Agents Guide.

See the Service Account Security Guide and the SaaS API Token Security Guide.

Logging and detection

Workday's public security page states that audit trails, user activity logs and sign-on reports are available, and that failed logins and successful logins and logouts are logged. Configuration changes to business objects carry an audit trail, and security policy activations carry the comment entered at activation. User activity logging must be enabled in tenant setup to capture which tasks and reports users ran, so confirm it is on before you need it.

Forward Workday activity to the SIEM through a scheduled report or an integration that itself runs under a read-only ISU, and correlate it with identity provider and HR ticketing data. Payroll diversion fraud (changing a worker's bank account after taking over their account) is one of the most common practical abuses, so alert on bank detail changes followed by a payroll run. See the MFA Guide.

Metrics that show it is working

• Privileged groups: number of members of security administration groups, reviewed monthly, with zero unexplained additions.
• ISUs: percentage with a named owner, "Do Not Allow UI Sessions" selected, a dedicated group and a rotation date in the last 12 months.
• Unconstrained integration groups: count, trending down as integrations are moved to constrained groups.
• API clients: number with non-expiring refresh tokens and number without an owner.
• Native logins: count of sign-ins that bypassed SSO outside approved break-glass use (target: zero).
• Access reviews: completion rate for security group and domain policy certifications. See the Access Reviews Guide.

Hardening baseline

Decision guidance

• Constrained or unconstrained integration groups: choose constrained whenever the vendor serves part of the workforce (one country's payroll, one subsidiary's benefits). Unconstrained is justified for identity provisioning that must see every worker; record why.
• Basic authentication or OAuth: where the connector supports it, OAuth with scoped API clients is easier to inventory and revoke than an ISU password. A non-expiring refresh token, however, is no better than a password, so prefer expiring tokens if the tool can refresh.
• Smaller tenants: with one or two Workday administrators, full segregation of duties may be impossible. Compensate with peer review of pending changes, monthly reports of group membership and an external review of security configuration each year.
• Larger tenants: split HR, payroll, finance and security administration into separate groups, put security policy activation behind change management, and run quarterly certifications of every privileged and integration group.

Phased rollout

1. Inventory (weeks 1 to 3): export all security groups with members, all ISUs, all API clients and all domains granting Modify or Put. Assign an owner to each integration.
2. SSO and authentication (weeks 3 to 5): enforce SSO for all workers through authentication policies, restrict native passwords to break-glass accounts and test the login.flex?redirect=n path yourself. Pilot on a small population, keep an administrator session open while changing policies, and keep the previous policy for rollback.
3. Integrations in a sandbox first (weeks 5 to 10): move each integration to its own ISU and constrained group in a sandbox or implementation tenant, run the integration end to end, then repeat in production. Roll back by restoring the previous group membership, which is a single pending change.
4. Privileged groups (weeks 6 to 8): reduce membership, separate editing from activation and set up alerts.
5. Logging (week 8): enable user activity logging and feed the SIEM.
6. Ongoing: certify groups and integrations quarterly, rotate ISU passwords, certificates and secrets on a schedule, and review the security configuration after each Workday release.

Common misconfigurations

• One ISU for many integrations: its group collects every domain any vendor ever needed, and no single owner can rotate it without breaking something.
• Integrations running as administrators: implementation shortcuts that survive go-live give a third party full tenant access.
• Policies changed but never reviewed: because effective access comes from policies as well as memberships, a review that only lists group members misses that a broad group gained Modify on a sensitive domain.
• Non-expiring credentials with no inventory: ISU passwords exempt from expiry and non-expiring refresh tokens accumulate at former vendors.
• SSO without closing native login: SSO and MFA at the identity provider mean little if any user can still sign in with a Workday password through the fallback URL.
• Weak help desk verification: MFA resets and payroll changes approved over the phone undo every technical control.

Framework mapping

Workday's compliance page lists, among others, SOC 1 Type II, SOC 2 Type II (with a SOC 2+ mapping to NIST CSF and NIST SP 800-171), ISO/IEC 27001:2022, 27017, 27018, 27701 and 42001, and FedRAMP Moderate for Workday Government Cloud. These cover Workday's side of the shared responsibility model; the configuration in this guide is the customer's side.

Practitioner checklist

• Export and review every security group that can edit security policies, activate changes or edit tenant security setup.
• Give each integration its own ISU with "Do Not Allow UI Sessions" selected and a named owner.
• Move integrations to constrained integration system security groups with only the Get and Put domains they need.
• Inventory API clients in View API Clients, remove unowned ones and justify every non-expiring refresh token.
• Enforce SSO with phishing-resistant MFA and restrict native passwords to vaulted break-glass accounts.
• Require peer review before Activate Pending Security Policy Changes and keep the audit comments as evidence.
• Enable user activity logging and alert on privileged group changes, new ISUs or API clients and bank detail changes.
• Certify privileged and integration groups quarterly and re-check configuration after each Workday release.

Standards and references

• Workday: Security
• Workday: Compliance
• Microsoft Learn: Configure Workday to Microsoft Entra user provisioning
• Microsoft Learn: Microsoft Entra SSO integration with Workday
• Workato: Workday connector setup
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Additional Cloud Roles

Related NHI Mgmt Group resources: SaaS Security Guide · SaaS and OAuth App Governance Guide · Top 10 SaaS Security Risks · SaaS Security Buyer's Guide · Salesforce Security Guide