UKG Pro Security Guide: Roles, SSO, API Accounts

UKG Pro holds employee identity, pay and bank details, so a single over-privileged role or a reused web service password can expose the most sensitive data an organisation keeps and open the door to payroll diversion. Security in UKG Pro rests on settings the customer owns: role-based security with roles and qualifiers, how users sign in (direct login or SAML single sign-on), the account lifecycle rules in User Administration, and the web service accounts that integrations use. This guide covers each of those with the menu paths UKG documents, plus monitoring, a baseline and the process controls that stop fraudulent bank detail changes. It is for HRIS administrators, identity engineers and security teams supporting UKG Pro.

This is an independent guide from NHI Mgmt Group, based on UKG's public documentation as of November 2026. It is not sponsored or reviewed by UKG. Product features change, so confirm settings against UKG's current documentation.

Key takeaways

Roles plus qualifiers define reach. Every UKG Pro user needs at least one role, and administrators can act only on the users their roles and qualifiers let them see, so scope qualifiers as carefully as roles.
Federate sign-in and enforce MFA at the IdP. UKG Pro supports SAML SSO, set up with a UKG SSO engineer; make your identity provider the place where MFA and conditional access apply.
One service account per integration. UKG recommends service accounts for web services, each with its own user API key and only the Add, Delete, View or Edit methods it needs.
Use account statuses deliberately. Suspend on termination, rely on the 180-day inactivity rule as a backstop, and treat the View Default Password right as privileged.
Bank detail changes need an out-of-band check. Pair UKG Pro change data with notifications and payroll review so a hijacked self-service session cannot quietly redirect pay.

How identity and access work in UKG Pro

UKG Pro separates who a user is from what they can reach.

Element	What UKG documents	Customer decision
Account types	Employee accounts for existing employees; Guest (Non-Employee) accounts for auditors, contractors and similar, without the Myself menu	Use guest accounts for outsiders and give them end dates in your own records
Creation	System Configuration > Security > User Administration > Add; bulk creation for groups with the same roles and qualifiers; accounts can start Active or Suspended	Create suspended, activate on start date
Roles and qualifiers	Assigned on the Roles and Qualifiers page; at least one role per user	Least privilege by role, scoped by qualifier
Web access rights	Per-role rights under System Configuration > Security > Role Administration > Web Access Rights	Review sensitive rights per role
Sign-in	Direct login, or SAML SSO configured with UKG	Federate, and enforce MFA at the IdP

Single sign-on

UKG's SSO setup guide asks the customer to send their identity provider's federation metadata and the tenant's vanity URL to a UKG Pro SSO engineer (via [email protected]), who completes the connection, typically within three to five business days, and supplies test and user provisioning documentation. Microsoft's Entra ID tutorial for UKG Pro describes the same pattern: SP-initiated SAML, with the identifier and reply URLs supplied by UKG, and each Entra user linked to a matching, active UKG Pro user.

UKG's documentation for its authentication upgrade adds settings to check on newer tenants: up to seven SSO connections, each with its own vanity URL; the HTTP POST binding; Sign SAML request and Notify IdP about callbacks selected for the most secure connection; and SAML 2.0 single logout, which ends IdP sessions when users sign out. The username in UKG must match the SAML response exactly. Confirm with UKG which authentication model your tenant runs before changing anything.

With SSO in place, enforce phishing-resistant MFA and device conditions in your IdP; see the SAML Security Guide and the Phishing-Resistant MFA Guide. Where users still sign in directly, UKG Pro asks for an access code when MFA is enabled; keep direct login to the smallest group you can.

Account statuses

Inactive: after 180 days without a successful login, or 30 days without first login on a default password.
Restricted: a 30-minute lockout after five consecutive failed sign-ins.
Locked: after failed challenge answers or failed attempts to set a compliant password; only an administrator can reactivate.
Suspended: blocks portal access until an administrator reactivates. System Settings can apply it automatically to new hires (when Active Upon New Hire is not set) and to terminated users (Suspended Upon Termination).

Admin roles and privileged access

Administrative power in UKG Pro comes from roles with security, payroll or system configuration rights. Treat these as privileged accounts.

System administrator rights: needed to create web service accounts under System Configuration > Security > Service Account Administration. Limit to a small, named group.
View Default Password: a web access right under Role Administration > Web Access Rights > Security > User Administration. Anyone with it can see a user's default password after a reset, so grant it only to the service desk role that performs resets.
Reset Password: restores the default password and sets the account Active. Require a verified ticket for resets, especially for payroll and HR administrators.
Qualifiers on admin roles: scope HR administrators to the companies or populations they support, so one compromised admin cannot reach every employee.
Separate duties: keep the role that edits bank details apart from the role that approves or releases payroll.
Review: reconcile role holders with HR status quarterly; see the Access Reviews Guide and the SaaS Admin Account Protection guide.

Integrations, API tokens and service accounts

UKG Pro web services (SOAP 1.2 and JSON or XML REST over HTTPS) are reached with a web service account. UKG's API guide recommends a service account over a web user.

Credential element	Where it lives	Handling
Customer API key	Service Account Administration and Web Services pages	Shared across the company; treat as an identifier, not a secret on its own
User API key	Generated per service account	Unique per account; store with the password
Username and password	Set when the account is created; the generated password is shown once	Store in a secrets manager immediately; regenerate if lost
Method permissions	Per web service: Add, Delete, View, Edit	Grant only the methods the integration uses
Status	Active or Suspended	Suspend accounts no longer in use

One account per integration: UKG notes each web service you use needs its own service account; extend that to one per partner so you can suspend a single integration without affecting others.
Share credentials narrowly: UKG's guidance is to distribute them only to developers who need access. Send them through a secrets manager or secure share, never email.
Watch last logon: the account details page shows last logon date and time. Suspend accounts that have not logged on for your inactivity threshold.
Reporting access is separate: service accounts do not get Business Intelligence access automatically; it is granted through an administrative case. Keep reporting rights off integration accounts that do not need them.
Use company codes on updates: UKG notes that updates should include a company code where an employee exists in several companies, so changes land on the correct record.

UKG Webhooks send near real-time notifications when data such as addresses or emergency contacts changes, and can drive downstream actions such as removing access on termination. Protect the receiving endpoint like any API: authenticate requests, use HTTPS and log what arrives. Govern these accounts as non-human identities; see the API Key Management Guide and the Non-Human Identity (NHI) Guide.

Logging and detection

Combine what UKG Pro shows with your IdP and integration logs.

IdP sign-in logs: for federated users, the IdP is where impossible travel, new device and MFA failure signals appear. Alert on sign-ins to UKG Pro from risky sessions.
User Administration: review account statuses (Restricted and Locked spikes suggest password guessing), new guest accounts and role changes.
Service accounts: review last logon times and status on the Service Account Administration page; alert on activity from accounts you believed retired.
Change data on sensitive fields: use UKG Pro reporting, or webhooks where your tenant exposes the event, to capture changes to direct deposit, address and email fields, with who made them and when. Confirm with UKG which events and audit reports your modules provide.

Metric	Target
Users signing in through SSO	All employees except a documented break-glass set
Holders of system administrator and View Default Password rights	Named, reviewed quarterly
Active service accounts with no logon in 90 days	Zero
Terminated employees still Active in UKG Pro	Zero within one business day
Direct deposit changes verified out of band before payroll	100%

Hardening baseline

Federate: work with your UKG SSO engineer to connect your IdP; enable signed requests, POST binding and single logout where your authentication model offers them.
Enforce MFA at the IdP: phishing-resistant methods for HR, payroll and system administrators first.
Lifecycle settings: set Suspended Upon Termination, create new users as Suspended until start date, and feed leavers from your HR-driven process; see the Joiner-Mover-Leaver Guide.
Roles: map every role to a job function, remove unused roles, scope admins with qualifiers, restrict View Default Password.
Service accounts: one per integration, minimum methods, passwords and API keys in a vault, unused accounts suspended.
Payroll change controls: notify employees of bank detail changes through a channel other than the one used to make the change, hold first payments to new accounts for review, and call back on a known number for any change requested by email or phone.
Test and roll back: test SSO in a non-production tenant first; UKG's upgrade flow lets production tenants switch to direct login if an unused SSO connection needs removing, so keep a break-glass admin who can sign in directly.

Decision guidance

Decision	Option A	Option B	When to choose which
Sign-in	SAML SSO through your IdP	Direct login with UKG Pro MFA access codes	Choose SSO whenever an IdP exists; keep direct login for a documented break-glass administrator and any population the IdP cannot serve
Integration identity	Service account	Web user account	UKG recommends service accounts; use them for every integration so permissions are per web service and not tied to a person
Change detection	Webhooks to a receiving service	Scheduled reports reviewed by payroll	Webhooks suit organisations with an integration platform and SOC; scheduled review before each payroll run suits smaller teams
Admin scoping	One HR admin role for all companies	Admin roles scoped with qualifiers per company or population	Single-company organisations can keep one role with few holders; multi-company groups should scope with qualifiers

Smaller organisations often run UKG Pro with a handful of administrators who share payroll, HR and system tasks. In that case separation of duties is still possible with process: the person who changes bank details should not be the person who releases payroll, and every change should be confirmed with the employee by phone on a number already on file. Larger organisations can push the same controls into roles, qualifiers and automated alerts. In both cases the integration accounts deserve the same scrutiny as people, because a service account with Edit on employee web services can change pay data at scale.

Common misconfigurations

Shared integration account: one service account used by several partners makes it impossible to revoke one without breaking all. Split them.
Edit and Delete granted "just in case": grant View only where an integration reads data.
Passwords kept in email threads: the generated password is shown once for a reason; store it in a vault and rotate if it was ever emailed.
Terminated users left Active: without Suspended Upon Termination or HR-driven deprovisioning, leavers keep self-service access until the 180-day rule catches them.
Self-service bank changes with no verification: a phished employee login is enough to redirect pay. See the Payroll Diversion Fraud Guide.
Unscoped HR admin roles: roles without qualifiers can see every employee in every company.

Framework mapping

Control area	NIST SP 800-53 Rev 5	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A
SSO and MFA	IA-2, IA-8	6.3, 6.5	A.8.5 Secure authentication
Lifecycle and statuses	AC-2 Account Management	5.3, 6.2	A.5.18 Access rights
Roles, qualifiers, admin rights	AC-3, AC-6	5.4, 6.8 Role-based access control	A.5.15 Access control, A.8.2 Privileged access rights
Service account credentials	IA-5 Authenticator Management	5.6 Centralise account management	A.5.17 Authentication information
Change monitoring	AU-2, AU-6	8.2	A.8.15 Logging

Relevant ATT&CK techniques for detection planning: T1078.004 Cloud Accounts (stolen employee or admin logins) and T1098 Account Manipulation (role or contact detail changes).

Practitioner checklist

Federate UKG Pro to your IdP and enforce MFA there.
Turn on signed SAML requests and single logout where available.
Set Suspended Upon Termination and create new users as Suspended.
Scope every admin role with qualifiers and restrict View Default Password.
Create one service account per integration with minimum methods.
Store service account passwords and user API keys in a vault.
Suspend service accounts with no logon in 90 days.
Verify every bank detail change out of band before the next payroll.
Review role holders and service accounts quarterly.

UKG Pro Security: Secure Roles, SSO, Service Accounts and Payroll Changes