Personio Security: How to Lock Down Roles, Logins, APIs and Payroll Data

Personio holds salary, payroll, bank, contract and identity data for every employee, so the people who can sign in, the roles they hold and the integrations that read through the API decide how well that data is protected. Most of the protection sits in a few customer-side settings: login methods, two-factor authentication, session timeout, the Administrator and HR Manager roles, approval workflows for data changes, custom integration credentials and the Audit Log. This guide explains how to configure each of them, with menu paths and values from Personio's own help centre. It is written for Personio administrators, HR systems owners, IT and identity teams, and security teams who review HR SaaS. Payroll diversion, where a fraudster changes an employee's bank details, is a recurring HR risk; the controls here make that change visible and approved. See the Payroll Diversion Fraud Guide for the fraud pattern itself.

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

Key takeaways

• Move everyone to SSO, then test before you switch off passwords. Personio supports SAML 2.0, OpenID Connect, a native Microsoft Entra ID connection and Google SSO; run the configuration test before making SSO the only enabled method.
• Cover password users with 2FA. 2FA applies to Personio Credentials logins, can be required for all employees or per role, and should always be on for the Administrator role.
• Keep Administrators few. Personio describes Administrator as the highest level of access and recommends a small number; give everyone else a narrowly scoped custom role.
• Route bank detail changes through approval. Give employees Propose (not Edit) rights on the profile section that holds payroll data and attach an Employee data change approval workflow with an email step.
• Treat API credentials as privileged. Role permissions do not limit what a custom integration reads, so grant only the areas and attributes it needs, store the secret in a vault and review integrations quarterly (our cadence).

How identity and access work in Personio

Every person who signs in to Personio has an employee profile, and every login is matched to that profile by email address. Access inside the product is then set by employee roles. Login configuration lives in Settings > Security & integrations > Security & authentication, which is open to users with the Administrator role and to employees whose role has edit permission for Account configuration > Authentication.

Each method shows a status of Not configured, Configured or Enabled. At least one method must always be enabled, several can be enabled at once, and which methods you see depends on your Personio plan.

SAML setup details

The path is Security & authentication > SAML > Configure (or Manage for an existing setup). Personio gives you an ACS URL, an Entity ID and an optional signing certificate (.cer or .pem) for the identity provider. In Personio you enter the identity provider's metadata XML URL, optional button text (default "Continue with SSO") and optional Home Realm Discovery domains. Points that matter for security and availability:

• Name ID: set the identity provider's Name ID format to email address. The email in the assertion must match an existing employee profile or access is denied, which means SSO does not create Personio users.
• Service provider initiated only: logins start from Personio; identity provider initiated SSO is not used. Requests are signed with RSA-SHA256 and sent by HTTP-POST.
• Home Realm Discovery: listed email domains go straight to the identity provider. With Home Realm Discovery on, those domains use SAML instead of email and password even when Personio Credentials stays enabled.
• Certificate renewal: Personio does not detect identity provider changes. After a certificate rollover, update the metadata XML URL and save to re-sync. Track the certificate expiry date shown after saving.
• Test first: run the configuration test while signed in as an admin whose email exists in the identity provider, and only then make SAML the only method.

See the SAML Security Guide for identity provider side settings.

2FA and sessions

2FA is set under Personio Credentials > password and 2FA settings > Two-factor authentication (2FA), for all employees or for chosen roles, including Administrator. To target a few people, Personio suggests creating a role with no extra permissions, adding them and enabling 2FA for it. 2FA does not apply to SSO logins, because the identity provider handles MFA there. Admins can reset a user's 2FA from the profile (three dots > Manage account). Self-service reset is a role permission (Manage accounts, edit access for Own); keep it off for Administrator and HR Manager roles so a reset goes through a second person.

The session inactivity timeout offers 10 hours, 3 days (default), 1 week or 1 month. It applies to the whole organisation, covers the web app only (mobile sessions last 30 days), and takes effect at next login. Our recommendation for HR data is 10 hours. Changes are recorded in the Audit Log.

Admin roles and privileged access

Personio separates one full-control role from configurable employee roles. Roles are managed in Settings > People > Roles & permissions.

Personio places no limit on the number of Administrators but recommends keeping it low, because many administrators make account-wide changes hard to trace. Give everyone else who needs elevated access a custom role. Watch these permissions in particular, because each one changes who can reach everyone's data:

• Account configuration > Authentication: changes login methods, 2FA and session timeout.
• Marketplace Integration and API (edit): creates and edits integrations and their credentials.
• People data > Salary and Payroll: sees and changes pay and bank information.
• Manage accounts: resets passwords and 2FA for others.

See SaaS Admin Account Protection and the Segregation of Duties Guide.

Approval workflows for bank and payroll changes

Personio's Employee data change approval template (Automations > Create workflow > Approvals) puts a second person between a proposed change and the record. How it works, from Personio's docs:

• Propose versus Edit: only users with Propose permission trigger approvals. Users with Edit permission change data directly.
• Conditions: a workflow triggers on a profile section, such as payroll information, and rules can narrow it to groups of employees. With an active payroll integration, some payroll attributes cannot be used as conditions, so check the section you need is selectable.
• Approvers: up to four named users per step, an employee role, or additional supervisors. Several steps form a chain; each step moves on when one approver acts.
• Notifications: approval tasks do not send reminders or emails by default. Add an email step, and consider one that notifies the employee whose bank details changed, so they can report a change they did not make.
• Fallthrough: changes that match no workflow are approved automatically, and where several workflows match, the highest priority applies. Give the payroll workflow high priority.

Our recommended pattern: employees hold Propose on the section that contains bank details, a payroll team member approves, and anyone approving confirms the change through a known channel (not a reply to the request). Administrators monitor pending items in Automations > Activity.

Integrations, API tokens and service accounts

Every Personio integration that reads employee data is a non-human identity with standing access to HR records. Personio has two kinds:

• Personio-managed credentials: created automatically for the Recruiting API, Personio's own integrations and partner integrations from the Marketplace. Personio manages these; you govern them by deciding which integrations to connect and by disconnecting unused ones.
• Custom integrations: created in Marketplace > Connected Integrations > Create custom integration. This needs the Core Pro plan and edit rights for Marketplace Integration and API. Each authenticates with a Client ID and API secret.

Org Units, Legal Entities, Cost Centers, Workplaces and Reports are read-only areas. Write permission does not include read, so an integration that must read back what it writes needs both.

Important: employee role permissions do not restrict what a custom integration can reach through the API, and API access cannot be limited to employees in a specific role. The integration's own area and attribute settings are the only boundary, so design them as carefully as an HR Manager role.

Credential lifecycle

1. One integration per system, named for the system and with a named business and technical owner (our rule).
2. Store the secret in a secrets manager and never in scripts, spreadsheets or tickets.
3. Reset credentials from the integration's window in Marketplace > Connected integrations when the owner changes, when a secret may have been seen, and on a fixed schedule; our recommendation is every 90 days.
4. Disable (temporary) when an integration is paused, and Disconnect (permanent deletion) when it is retired.
5. Review quarterly: list connected integrations, their areas and attributes, and webhook targets.

See the SaaS API Token Security Guide, the SaaS and OAuth App Governance Guide and, if a secret leaks, the Work SaaS API tokens response guide. For HR-driven joiner, mover and leaver flows into other systems, see the Identity Lifecycle Event Design Guide.

Logging and detection

The Audit Log is at Settings > Data Governance > Audit Log and only Administrators can open it. It records changes to company and employee data, including actions by Personio Support agents through Personio Support Access, grouped into categories such as Employee information, Salary, Compensation, Documents, Permissions, Login, Subscription and Recruiting. Entries are read-only, new events can take up to two hours to appear, and each entry shows Performed by, Logged in as (the employee being impersonated, where relevant), Applied to, action type, description and timeframe, with a timestamp and Personio Trace ID in the details. IP addresses are not shown in the log. Filtered results export as CSV to the Administrator's Personio inbox.

Personio does not state a retention period in this article, so export the log on a schedule (our recommendation: monthly, plus before any payroll investigation) and keep it in your own store. Correlate with identity provider sign-in logs for IP context. See the SaaS Audit Log Retention and Licensing Guide.

Metrics that show it is working:

• Share of employees signing in through SSO (target: everyone with a corporate identity).
• Share of Personio Credentials users covered by 2FA (target 100%).
• Number of Administrators (target three or fewer) and roles with Payroll or Authentication rights.
• Bank detail changes made through an approval workflow, as a share of all bank changes (target 100%).
• Custom integrations with an owner, a reset in the last 90 days, and no unused areas.
• Days between the last Audit Log export and today.

Hardening baseline

A phased rollout. Most changes revert from the same screen, but switching off Personio Credentials and resetting API credentials both interrupt users or integrations, so schedule them.

1. Inventory: list Administrators, every role with Authentication, Marketplace, Payroll or Manage accounts rights, all connected integrations and webhook targets, and current login methods.
2. Protect admins first: require 2FA for the Administrator role and reduce Administrators to named owners.
3. Configure SSO (SAML, OIDC or a native connection) alongside Personio Credentials, run the configuration test, then add Home Realm Discovery for your corporate domains.
4. Require 2FA for all remaining Personio Credentials users, including activation code users.
5. Set the session timeout to 10 hours (our recommendation).
6. Rework roles: move elevated users to custom roles, give employees Propose on payroll and bank sections, and remove self-service 2FA reset from privileged roles.
7. Build the payroll approval workflow with an email step and high priority, test it with a pilot group, then apply it to all employees.
8. Tighten integrations: trim areas and attributes, turn off the Custom Reports all-attributes option where not needed, move secrets to a vault and reset them.
9. Start monthly Audit Log exports and a quarterly access and integration review.

Common misconfigurations

• Edit rights on bank details for all employees: Edit bypasses approval workflows. Use Propose so the workflow applies.
• Approval workflow with no notification: tasks send no email by default, so changes wait unseen. Add an email step.
• Assuming role permissions limit the API: they do not. Scope each custom integration's areas and readable attributes.
• Too many Administrators: every Administrator can change login methods and see the Audit Log. Use custom roles.
• Passwords left as a quiet fallback: without Home Realm Discovery, staff can still choose email and password. Add your domains or require 2FA.
• Stale SAML metadata: a certificate rollover at the identity provider breaks sign-in until the metadata URL is re-synced. Track the expiry date.

Apply Personio's product and security updates as they are published, and follow its Login and Data Security articles for changes.

Framework mapping

Personio processes personal data of employees, so these controls also support security of processing under GDPR Article 32. See the GDPR Compliance Guide for Security Teams and, for employee access requests, the DSAR Guide.

Practitioner checklist

• SSO configured and tested; Home Realm Discovery set for corporate domains.
• 2FA required for the Administrator role and all Personio Credentials users.
• Session timeout set to 10 hours (our recommendation).
• Three or fewer Administrators; elevated access through custom roles.
• Authentication, Marketplace, Payroll and Manage accounts rights reviewed quarterly.
• Employees hold Propose, not Edit, on payroll and bank sections.
• Employee data change approval workflow on payroll data, with an email step and high priority.
• Each custom integration scoped to needed areas and attributes, owned, and its secret in a vault.
• API credentials reset every 90 days and on owner change; unused integrations disconnected.
• Audit Log exported monthly and reviewed for permission, login and salary changes.

Standards and references

• Personio: Overview of the Security & authentication area
• Personio: Set up single sign-on (SSO) with SAML 2.0
• Personio: Enable two-factor authentication (2FA) for employee roles
• Personio: Manage session timeout for your organization
• Personio: Frequently asked questions about employee roles and permissions
• Personio: Set up employee data change approval workflows
• Personio: How to generate and manage API credentials for personnel data
• Personio: Use the Personio Audit Log

Related NHI Mgmt Group resources: Payroll Diversion Fraud Guide, SaaS API Token Security Guide, SAML Security Guide, Segregation of Duties Guide, SaaS Security Guide.