ADP Workforce Now Security: Roles, Federated SSO, API Access and Payroll Fraud Defence

ADP Workforce Now holds pay rates, bank accounts, tax identifiers and home addresses for every employee, so one over-permissioned practitioner, one phished administrator or one unverified bank change can divert salaries or expose the whole workforce. Most attacks on payroll platforms do not break the software: they abuse legitimate accounts, self-service registration and change requests that look routine. This guide covers how identity and access work in ADP Workforce Now (WFN), administrator and practitioner roles, federated single sign-on, API and marketplace integrations, the reports that act as your audit trail, and a hardening baseline aimed at payroll diversion. It is written for HRIS and payroll administrators, identity engineers and security teams. ADP's detailed administrator help sits behind a customer login; this guide uses ADP's public federation guide, developer guides, security management guide and data security pages as checked in November 2026, so confirm menu names in your own instance.

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

Key takeaways

• Federate administrators first. ADP Federated SSO supports SAML 2.0 and OpenID Connect, and ADP's Global Security Office strongly recommends identity provider MFA for administrators, which makes your identity provider the control point for the most dangerous accounts.
• Watch for dual access users. Federated users have no ADP password, but users who also register a full ADP user ID and password keep a second way in that bypasses your identity provider; federated-only access must be requested from ADP and does not remove existing dual accounts.
• Practitioner access is payroll power. Access permissions such as "View & Edit Access to all People" and "All company codes -View & Edit" let a user, or an integration account, read and change every employee's pay data.
• Do not rely on a notification you do not have. ADP's public guidance makes bank account changes something to review on the personnel report, and the Direct Deposit API documents no event notifications, so build your own review of every bank change before payroll is submitted.
• Verify every bank change out of band. ADP's own security alert describes emails impersonating employees that ask payroll staff to change bank details; confirm every request by phone or in person with a known contact.

How identity and access work in ADP Workforce Now

WFN has three broad populations: administrators and practitioners who run HR and payroll, managers who approve and view their teams, and employees who use self-service to view pay statements and change personal details such as address and direct deposit. Practitioner access is scoped by access permissions; in WFN these are set under Setup, Security, Access Permission, Payroll and People Access, with separate tabs for People Access and Payroll Processing Access by company code.

Security administration roles

ADP's Security Management Service guide for security administrators describes a role hierarchy that separates who manages security from who uses the HR and payroll services. Confirm the equivalent roles in your WFN instance, as ADP products present them differently.

Self-service registration

Employees register with either an organisational registration code or a personal registration code. ADP's security management guide describes the organisational code as the client ID, a hyphen and an organisation-chosen code, recommends changing it every three months and treating it as confidential, and describes personal codes as random, tied to one person and expiring once used or after 15 days. ADP's payroll fraud page advises limiting the company registration code to those who need it, distributing it securely, using back-end validation and asking ADP about personal registration codes. An organisational code posted on an intranet page lets anyone who knows an employee's identifying details try to register as them, so prefer personal codes. The same guide says administrator logins are risk-scored against previous successful logins and may require a code sent to email or mobile, or security question answers, when risk is elevated, and that users are notified when their contact email or mobile number changes.

Admin roles and privileged access

The accounts that can change pay, bank details and access permissions are your privileged identities, even though they look like ordinary business users. ADP's payroll fraud guidance tells clients to review all client administrator and practitioner roles for accuracy, appropriateness and current contact information using the access control report, and to split payroll tasks so that one person prepares the payroll and another submits and verifies it.

• Scope practitioners by company code and population: avoid "All company codes -View & Edit" and "View & Edit Access to all People" except for the few people whose job needs it. Give view-only access to auditors and analysts.
• Separate preparer and approver: the person who keys bank or pay changes should not be the person who submits the payroll. Where your instance supports approval workflow on direct deposit changes, turn it on.
• Federate administrators and protect their launch link: the ADP federation guide recommends protecting the administrator relay state or OIDC web destination link with MFA at the identity provider. Use phishing-resistant MFA for these accounts. See the Phishing-Resistant MFA Guide.
• Change credentials when payroll staff change: ADP advises changing payroll system passwords whenever payroll administration personnel change; with federation, disable the leaver in the identity provider and deprovision their PID the same day.
• Keep ADP's contact for you current: ADP asks clients to keep payroll administrator contact details up to date so it can reach them about suspicious activity.

Federated SSO and provisioning

ADP Federated SSO makes your organisation the identity provider and ADP the service provider. It is configured in the Federation Dashboard at identityfederation.adp.com after an ADP representative provisions your Federation Admin.

Because WFN is often the source of truth for joiner, mover and leaver events, protect both directions: the identity provider controls who signs in to ADP, and ADP data may drive accounts elsewhere. See the Joiner-Mover-Leaver Guide and the Identity Lifecycle Event Design Guide.

Integrations, API tokens and service accounts

Integrations reach WFN through ADP's APIs and the ADP Marketplace. ADP's Direct Deposit API guide shows the pattern: a consumer application is registered in the Consumer Application Registry (CAR) with the canonical URIs it may call, and scopes are specific, for example worker.payDistribution.read and worker.payDistribution.change. Changes are submitted as events such as worker.pay-distribution.change with a role code of Practitioner or Employee. In the employee (B2C) flow, the user signs in with their employer-issued ADP credential and consents to the application reading their direct deposit data.

• Treat integration credentials as privileged non-human identities: client credentials and any certificates issued for API access let an application act on payroll data without a person present. Store them in a secrets manager, record an owner and an expiry, and rotate them on a schedule. See the Secrets Management Guide and the API Keys vs OAuth Tokens Guide.
• Request only the scopes needed: an application that reads headcount does not need worker.payDistribution.change. Review the canonical URIs registered for each application in CAR.
• Dedicated practitioner accounts for connectors: marketplace and HRIS connectors commonly run under a practitioner user. Give each connector its own account, scoped by company code and population, never a person's account and never "View & Edit Access to all People" unless the integration needs it. See the SaaS API Token Security Guide.
• Know the API's blind spots: ADP lists known issue US1130068, no supported event notifications for the Direct Deposit API, and US871362, where a change that enters a client-configured workflow is not flagged in the API response. Downstream systems must poll and reconcile rather than assume a change was applied.

Logging and detection

ADP's public guidance leans on reports reviewed every payroll cycle rather than real-time alerts, so make those reviews a named, evidenced control.

ADP's payroll fraud page lists warning signs worth turning into alerts or checklist items: a payroll preview email for a payroll you did not submit, a payroll transmitted unexpectedly, employees reporting unexpected deposits, changes you did not make such as an employee's status, and payments to terminated or non-existent employees. In ATT&CK terms, payroll diversion combines T1566 Phishing or T1078 Valid Accounts for access with T1657 Financial Theft as the outcome.

Metrics

• Percentage of administrators and practitioners on federated SSO with MFA, and number of remaining dual access users.
• Number of users holding all-company, all-people edit access.
• Percentage of bank account changes verified out of band before the payroll that pays them.
• Diverted or recalled payments per quarter (target zero) and time from report to recovery attempt.
• Access control report reviews completed on time.

Hardening baseline

1. Inventory accounts: export administrators, practitioners and integration accounts, with access permissions and company codes. Remove leavers and shared accounts.
2. Federate administrators: configure ADP Federated SSO, enforce MFA at the identity provider for the administrator launch link, then federate practitioners. Pilot with HRIS staff and keep one documented break-glass administrator. See the Break-Glass Account Guide.
3. Close dual access: list users with both federated and full ADP credentials, and ask ADP to set federated-only access for administrators.
4. Tighten access permissions: replace all-company edit access with company code and population scopes; give view-only access where editing is not needed.
5. Lock down registration: move to personal registration codes, or rotate the organisational code and stop publishing it.
6. Build the bank change control: require out-of-band verification for every direct deposit change made by practitioners, review the personnel and split deposit reports before each payroll, and use approval workflow where available.
7. Review integrations: for each application, confirm the owner, scopes, CAR registrations, practitioner account scope and credential expiry.
8. Roll back safely: keep a record of previous access permissions before changes, and change one population at a time so that a payroll cycle is never run with untested permissions.

Small and large organisations

• Small employers: often one person prepares and submits payroll. Add a second reviewer for bank changes and the personnel report, even if that person is an owner or external accountant, and enable MFA everywhere ADP offers it.
• Large employers: federate everyone, automate provisioning by PID, route bank changes through workflow and send ADP-related identity events to the SIEM.

Common misconfigurations

• Emailed bank change requests actioned directly: ADP's June 2019 alert described emails using an employee's real name and signature asking payroll staff to change bank details, with subject lines such as "Urgent Payroll Request". Verify by phone or in person using contact details already on file. See the Payroll Diversion Fraud Guide and the Business Email Compromise Awareness for Finance Teams Guide.
• Federation without closing dual accounts: administrators keep an ADP password that is phishable and outside your identity provider's MFA and logging.
• Integration accounts with all-people edit access: a connector that only reads job data can change bank details if its practitioner account is over-scoped.
• Organisational registration code shared widely: anyone with the code and an employee's identifying details can attempt to register as that employee and change their deposit.
• Expired federation certificate: federated access stops and teams fall back to emergency workarounds; monitor the Expired Certificates report.
• Assuming the API tells you about changes: with no event notifications for direct deposit, downstream systems drift unless they reconcile regularly.

Framework mapping

Practitioner checklist

• Federate administrators and practitioners with ADP Federated SSO and enforce phishing-resistant MFA at the identity provider for the administrator launch link.
• Inventory dual access users and request federated-only access for administrators.
• Restrict "View & Edit Access to all People" and "All company codes -View & Edit" to the few roles that need them.
• Separate payroll preparation from submission and verification.
• Verify every bank account change out of band before the payroll that pays it, and review the personnel and split direct deposit reports every cycle.
• Replace the organisational registration code with personal codes or rotate it and stop publishing it.
• Give each integration its own scoped practitioner account and least-privilege API scopes, with vaulted credentials and a named owner.
• Monitor federation certificate expiry and deprovision PIDs the same day an employee leaves.
• Review the access control report monthly and after every payroll staff change.

Standards and references

• ADP: ADP Federation Guide
• ADP: Security Management Service, Getting Started Guide for Security Administrators
• ADP: Protection Against Payroll Fraud
• ADP Global Security Organization: Industry Alert, Payroll Fraud
• ADP Marketplace: Direct Deposit API Guide for ADP Workforce Now
• ADP Marketplace: Practitioner User Access Permission for ADP Workforce Now
• MITRE ATT&CK: T1657 Financial Theft

Related NHI Mgmt Group resources: Payroll Diversion Fraud Guide · Joiner-Mover-Leaver Guide · SAML Security Guide · Email Identity and BEC Guide