PeopleSoft holds payroll, student records, HR and finance data, so keeping PeopleTools patched and its identities tightly controlled protects all of it. Oracle publishes quarterly Critical Patch Updates and out-of-band Security Alerts, and applying them promptly is the customer-side control that matters most. This guide covers how identity and access work in PeopleTools (user profiles, roles, permission lists and row-level security), the privileged and system identities you must control, Integration Broker nodes and single signon, logging, and a hardening baseline with patching at its centre. It is written for PeopleSoft administrators, ERP security leads and auditors. Facts are taken from Oracle's PeopleTools documentation (releases 8.59 to 8.63) and Oracle security alerts, checked on 8 November 2026; menu paths and defaults vary by PeopleTools release, so confirm on your own system. For Oracle's other ERP suites, see the Oracle E-Business Suite and Fusion Security Guide.
This is an independent guide from NHI Mgmt Group, based on Oracle's public documentation as of November 2026. It is not sponsored or reviewed by Oracle. Product features change, so confirm settings against Oracle's current documentation.
Key takeaways
- Patch PeopleTools, not just applications. PeopleTools fixes are separate from application updates, so an up-to-date HCM or Campus Solutions image does not cover the tools line. Oracle releases Critical Patch Updates on the third Tuesday of January, April, July and October, and issues out-of-band Security Alerts when needed.
- Access is three layers deep. User profiles get roles, roles get permission lists, and permission lists grant pages, processes, queries and web services; row-level security then filters data. Review all four, not just roles.
- System identities hold the keys. The Connect ID, Access ID, PTWEBSERVER, domain connection, web server and integration gateway credentials let one compromised server reach the database and every integration partner.
- Nodes are machine identities. Integration Broker node authentication defaults to None; production nodes should use Password or Certificate, and single signon fails outright if the default local node is set to None.
- Sign-in logging is thin by default. Oracle describes PSACCESSLOG as a non-authoritative view, so web server, application server and database logs must reach your SIEM for real detection.
How identity and access work in PeopleSoft
PeopleTools security is built in layers, configured mostly through PeopleTools > Security.
| Object | What it does | Where it is managed | Review question |
|---|---|---|---|
| User profile | The account (OPRID): password, roles, primary and row security permission lists, Account Locked flag | User Profiles (USERMAINT component) | Is every active profile tied to a current person or documented system purpose? |
| Role | A job function grouping permission lists; can be static or rule-based (for example from LDAP role membership rules) | Roles (ROLEMAINT component) | Do roles map to real job functions, without toxic combinations? |
| Permission list | Grants access to components and pages, PeopleTools, processes, web services, query profiles and sign-in times | Permissions & Roles > Permission Lists | Which lists grant PeopleTools, security administration or broad query access? |
| Row security permission list | Controls which data rows a user sees (business unit, setID, department or project) | User profile and application security setup | Does it match the user's organisational scope? |
| Query security | Query profiles and query access group trees decide which records a user can query | Query profiles and query trees | Can ordinary users query sensitive records directly? |
Two behaviours catch reviewers out. Oracle's Project Costing documentation notes that row-level security restricts what a user sees on a page but does not restrict data selected by batch processes, so anyone who can run a process can reach rows outside their scope. And query access is separate from page access: a user denied a component can still read its tables if their query profile and access group tree allow it.
Authentication options include PeopleSoft passwords, LDAP (including LDAPS) through Signon PeopleCode, PeopleSoft-only single signon with the PS_TOKEN cookie, Oracle Access Manager as the single signon solution, the Web Server Security Exit for an upstream identity provider, and OAuth 2.0 service applications for API clients. Whatever you use upstream, every user still needs a valid user profile in each database. Password rules live on PeopleTools > Security > Password Configuration > Set Password Controls.
| Password control | Delivered default (per Oracle docs) | Recommended for PIA passwords |
|---|---|---|
| Minimum Length | 8 (maximum password length 32) | 14 or more if PeopleSoft passwords are used at all; better to authenticate through your identity provider |
| Password May Match User ID / Primary Email | Not selected | Keep not selected |
| Failed Logons (account lockout) | 5 | 5 or fewer, with alerting on locked privileged accounts |
| Password Expiration | Enabled, 180 days | Follow your policy; expiry applies only to PIA sign-in, not Application Designer, Application Engine or Data Mover |
| Password History | 0 | Retain at least several previous passwords |
| Purge User Profiles | Blank (off) | Set an inactivity period and schedule the PURGEOLDUSRS Application Engine program |
Oracle notes these defaults are installed on a new database but are not set automatically during an upgrade, so review long-lived systems and update older values.
Admin roles and privileged access
Privilege in PeopleSoft sits in a small set of places. Find them and you have found most of your risk.
- Security administrators: any permission list granting the security components (User Profiles, Roles, Permission Lists) can create a new administrator. Keep these to named people, review them monthly and require approval for changes.
- PeopleTools developer access: permission lists that grant Application Designer, Data Mover or definition security let users change code or run SQL against the database. Remove them from production except for controlled change windows.
- Query and process power users: broad query profiles and the ability to run processes that bypass row-level security amount to bulk data access.
- System identities: Oracle's Secure by Default page lists the credentials an administrator must set at install: Connect ID and Access ID (database), the database user profile, PTWEBSERVER (initial PIA sign-on after the web server starts), the domain connection password (Jolt between web and application server), the web server password and the integration gateway password. Each needs an owner, a vault entry and rotation after staff changes or any suspected compromise.
- Public and guest users: the KIOSK web profile enables public access for a Guest user, and single signon commonly needs a public access profile. Oracle advises keeping that profile minimal and using public access only for informational sites with no sensitive data.
Store configuration passwords encrypted with PSCipher, which uses AES in current releases. Generate a unique encryption key for your installation rather than relying on the delivered one, and protect the external key file. See the Least Privilege Techniques Guide.
Integrations, API tokens and service accounts
Integration Broker nodes, single signon trust and integration user IDs are the non-human identities of a PeopleSoft estate.
| Integration identity | Default or behaviour (Oracle docs) | Hardening |
|---|---|---|
| Node Authentication Option | None is the default; Password and Certificate are the alternatives | Use Certificate where partners support it, otherwise Password; never None on production nodes |
| Node password | Up to 88 characters; Create NodePassword generates a 32-character random value on the default local node | Generate it, store it in a vault, share it with partners out of band |
| Default User ID on a node | The user ID used for inbound requests unless an external user is supplied, and sent outbound | A dedicated integration profile per partner with only the service operations it needs, never a person's account |
| Service operation security | The authenticated user must be in the permission list assigned to the service operation | Separate permission lists per integration; review web service access in permission lists |
| PS_TOKEN single signon | Signed with a SHA1 hash over token fields plus the local node password, or with a certificate; trusted by named nodes; timeout set on PeopleTools > Security > Single Signon | Short timeout, Secure Cookie with SSL enabled, trust only the nodes you need |
| Transport | SSL/TLS on the web server, client authentication from application server to gateway (requires SSL/TLS), WS-Security UsernameToken or SAML token | TLS everywhere, WS-Security for SOAP partners, nonrepudiation enabled on the node and on each service operation that needs it |
| OAuth 2.0 service applications | Service applications receive access tokens; expired tokens can be deleted | One application per client, scheduled clean-up of expired tokens |
Oracle's node documentation is blunt: if the default local node uses None and single signon is implemented on the same system, all transactions fail. Because the PS_TOKEN signature includes the local node password, anyone who knows that password and the node name can forge tokens that a trusting system will accept, so treat it as a top-tier secret.
Cloud and file credentials on the servers matter just as much: review each server's service identities and keep every secret reachable from it scoped and rotated. See the Service Account Security Guide.
Logging and detection
| Source | What it gives you | Use it for |
|---|---|---|
| PSACCESSLOG | OPRID, LOGIPADDRESS, LOGINDTTM, LOGOUTDTTM, PT_SIGNON_TYPE, PT_SIGNOUT_REASON; queries PT_SEC_ACCESSLOG_USER, PT_SEC_ACCESSLOG_DAY, PT_SEC_CURUSER_LIST under PeopleTools > Security > Review Security Information > Access Log Queries | Session history; Oracle calls it non-authoritative, so do not rely on it alone |
| Sign-in attempt tracking | Sign-in attempt records, configured as described in Tracking User Sign-In Attempts (Security Administration) | Password spraying, lockouts of privileged profiles |
| Web server access logs (WebLogic) | Requests, paths, source IPs, response codes | Requests to management or environment paths, encoded path tricks, new URLs |
| Application server and Integration Broker logs | Service operation errors, node authentication failures | Unknown nodes, failed node passwords, unusual service operations |
| Database audit | Activity by the Access ID and direct SQL | Changes to security tables outside the online components |
| Host telemetry (EDR) | New files in web directories, child processes of the web or application server | Web shells (ATT&CK T1505.003) and remote access tools (T1219) |
High-value alerts: changes to user profiles that add security administration or PeopleTools permission lists; a new role or permission list in production outside a change window; sign-ins by system profiles such as PTWEBSERVER from anything other than the web servers; outbound connections from PeopleSoft hosts to new destinations; and web requests to PeopleTools environment management paths from the internet. The ShinyHunters reporting described a WAF bypass that URL-encoded one character of the request path, so normalise paths before matching. See the Web Shell Response Playbook.
Hardening baseline
- Patch first: confirm your PeopleTools release and patch level. Verify that every Oracle Security Alert for your release is applied, then schedule each quarterly Critical Patch Update (the next listed is 19 January 2027). Stay on a PeopleTools release that Oracle still supports.
- Reduce exposure: publish only the PIA and the integration gateway paths partners need through a reverse proxy; block environment management, administration and PeopleTools utility paths from the internet. Treat a WAF rule as a stopgap, never a substitute for the patch.
- Web profile: run production on PROD or a copy of it, never DEV (Oracle says never run production with DEV). Copy delivered profiles rather than editing them. Enable Secured Access Only and keep Secure Cookie with SSL selected; keep Show Connection Information and Show Trace Link at Signon off; set Days to Autofill User ID to 0 on shared machines; keep Inactivity Logout at the delivered 1,200 seconds or lower; keep Allow Public Access off unless the site is purely informational.
- System credentials: rotate the Connect ID, Access ID, PTWEBSERVER, domain connection, web server and gateway passwords, encrypt them with PSCipher using a unique key, and store them in a vault.
- Integration Broker: set every production node to Password or Certificate, generate the local node password, review Default User IDs and trusted single signon nodes, and enable TLS for all partners.
- Access review: remove PeopleTools and security administration permission lists from non-administrators, tighten query profiles and access groups, set password controls and schedule PURGEOLDUSRS. Test each change in a copy of production before promoting it; keep exports of the previous role and permission list definitions so you can roll back.
- Logging: forward web server, application server, Integration Broker and database logs plus PSACCESSLOG to the SIEM and build the alerts above.
Common misconfigurations
- Waiting for the next quarter: treating an out-of-band Security Alert as routine. Our recommendation at NHI Mgmt Group: apply Security Alerts promptly and treat WAF rules as a stopgap, not a substitute for the patch.
- Nodes left at None: the default node authentication with a powerful Default User ID lets anyone who can reach the gateway call service operations as that user.
- Upgraded but never re-secured: password controls and web profiles carried forward from old releases because upgrades do not apply the new defaults.
- DEV or TEST web profile in production: trace links and connection information exposed to users and attackers.
- Production cloned without scrubbing: test copies with real personal data, the same node passwords and the same system credentials, so a less protected test server becomes a path into production.
- Cloud keys on the app server: long-lived credentials in files or environment variables on PeopleSoft hosts (ATT&CK T1552.001), turning a web compromise into cloud access.
Framework mapping and metrics
| PeopleSoft control | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | Threat addressed (ATT&CK) |
|---|---|---|---|---|
| PeopleTools patching and Security Alerts | ID.RA-01, PR.PS-02 | SI-2, RA-5 | 8.8 | T1190 Exploit Public-Facing Application |
| Roles, permission lists, row security | PR.AA-05 | AC-2, AC-6 | 5.15, 5.18, 8.2 | T1078 Valid Accounts |
| Password controls, PSCipher, node passwords | PR.AA-01 | IA-5 | 5.17 | T1552.001 Credentials In Files |
| TLS and WS-Security for integrations | PR.DS-02 | SC-8 | 8.20 | Interception of integration traffic |
| Logging and review | DE.CM-03 | AU-6 | 8.15, 8.16 | T1505.003 Web Shell, T1219 Remote Access Tools |
Metrics to report monthly:
- Patch latency: days from an Oracle CPU or Security Alert to production deployment (target: alerts for internet-facing flaws within days, CPUs within 30 days).
- Privileged profiles: number of user profiles with security administration or PeopleTools permission lists, and change since last month.
- Node posture: percentage of active nodes using Password or Certificate (target 100%).
- Dormant accounts: active profiles with no sign-in for 90 days.
- Credential age: age of the Connect ID, Access ID, node and gateway passwords against your rotation policy.
Practitioner checklist
- PeopleTools release and patch level confirmed; applicable Security Alerts verified; next CPU scheduled.
- Environment management and administrative paths unreachable from the internet; WAF rules normalise encoded paths.
- Production uses a copy of the PROD web profile with Secured Access Only, Secure Cookie with SSL, and debug options off.
- System credentials rotated, PSCipher using a unique key, all stored in a vault with owners.
- Every production node uses Password or Certificate, with least-privilege Default User IDs and reviewed trusted nodes.
- Security administration and PeopleTools permission lists limited to named administrators and reviewed monthly.
- Query profiles and access group trees reviewed for sensitive records; batch processes that bypass row security restricted.
- Password controls set explicitly after every upgrade; PURGEOLDUSRS scheduled.
- Web, application server, Integration Broker and database logs in the SIEM with alerts for security changes and web shells.
- Cloud and integration secrets on PeopleSoft hosts inventoried, minimised and rotated after any suspected compromise.
Standards and references
- Oracle: Critical Patch Updates, Security Alerts and Bulletins
- Oracle: PeopleTools Security Administration, Working With Passwords
- Oracle: PeopleTools Security Administration, Understanding Single Signon
- Oracle: PeopleTools Integration Broker Administration, Defining Node Parameters
- Oracle: PeopleTools Portal Technology, Configuring Web Profiles
- Oracle: PeopleTools Security Administration, Tracking User Sign In and Sign Out Activity
Related NHI Mgmt Group resources: Oracle E-Business Suite and Fusion Security Guide · Service Account Security Guide · Secrets Management Guide · Vulnerability Management Guide