Proton Pass Security: Organisation Policies and Sharing

Proton Pass for Business puts a company's shared logins, aliases and notes into end-to-end encrypted vaults, and the organisation policies, sign-in rules and sharing choices made by its admins decide who can reach them. This guide explains how to configure Proton Pass for Business securely, using Proton's own support and developer documentation as the source for every product detail. It covers the key hierarchy behind vaults, admin privileges, SAML SSO and SCIM, 2FA enforcement, the six team policies, vault sharing, CLI personal access tokens, the usage log and a phased hardening baseline. It is written for IT administrators, identity teams and security engineers running Proton Pass Professional or Proton Workspace. For the wider discipline see the Secrets Management Guide.

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

Key takeaways

• Every vault and item has its own key. Proton describes a random 32-byte key per vault and per item, encrypted with AES-256-GCM, with vault keys wrapped to each member's user key, so access is granted by sharing keys rather than by server-side permission alone.
• Six policies set the organisation's shape. Password generator rules, sharing outside the organisation, individual item sharing, data export, vault creation and required 2FA are the core controls, found under Admin panel > Proton Pass > Policies and Organization > Authentication security.
• 2FA is encouraged until you require it. Proton's default is that 2FA is strongly encouraged; switch on "Require 2FA for everyone", or at least for administrators, as one of the first changes.
• SSO and SCIM move identity to your IdP. SAML SSO handles sign-in and SCIM keeps users and groups in sync, so joiners and leavers follow the directory instead of manual invites.
• Machine access goes through personal access tokens. The Proton Pass CLI accepts a pst_ token scoped to chosen vaults or items, with 2-hour sessions, which you should treat as a non-human identity with an owner and a rotation date.

How identity and access work in Proton Pass

Proton's published security model for Pass sets out a three-level key hierarchy. Each user has an asymmetric user key, wrapped with a bcrypt hash of the account password (or the key password, where multiple account passwords are used) and the account salt. Each vault has a random 32-byte vault key, encrypted and signed with the user key. Each item has its own random 32-byte item key, encrypted under the vault key, and the item data is encrypted under the item key. Proton states that items, item keys and item data use AES-256-GCM, and its Pass security page states that vault keys are protected with OpenPGP using Curve25519. Authentication uses Proton's hardened Secure Remote Password (SRP) scheme, which Proton describes as limiting even an active attacker to one password guess per login attempt.

Proton states that usernames, passwords, web addresses and note contents are all end-to-end encrypted, so Proton cannot see which services members use. The practical effect for administrators is that the vault, not the organisation, is the unit of access: who holds a vault key is who can read it.

How sharing works

When a vault is shared, the member managing the vault encrypts the vault key to the recipient's address key and signs the invitation; the recipient verifies the signature and re-encrypts the vault key under their own user key. Sharing access levels in the apps are "Can view", "Can edit" and "Can manage", and the vault owner can change a member's role or remove access later from Manage access. Proton's sharing article also notes that if a vault owner deletes their Proton Account, the vault and its items are deleted for everyone, which matters for leaver handling (see Admin roles).

The sign-in chain

Single sign-on

Proton Pass supports SAML SSO on Proton Pass Professional with an admin account. Setup, per Proton's SSO article:

1. Add the company domain in the admin panel and verify it with the DNS TXT record shown.
2. Go to Single sign-on > SAML authentication > Configure SAML and import the IdP metadata by URL, XML file or text fields.
3. Copy the Assertion Consumer Service (ACS) URL and Issuer ID into the IdP.
4. Members then use "Sign in with SSO" in the Pass apps; they appear under Organization > Users after their first sign-in, and admins can change each user's SSO access from the Edit column.

Proton names Okta, Microsoft Entra ID and OneLogin as examples and publishes dedicated guides for Google, Microsoft and Okta. Up to five domains can be configured, each with identical SAML settings. Because the IdP authenticates the member, your Conditional Access and phishing-resistant MFA rules apply to Pass. See the Identity Provider and SSO Security Guide.

Admin roles and privileged access

Proton Pass for Business uses a per-user admin flag rather than a list of named roles. The admin guide describes it this way:

• Primary admin: the person who enables multi-user support (Settings > Organizations > Enable multi-user support) and names the organisation. They add and remove users and set permissions.
• Admins: admin privileges are off by default and are toggled per user from Organizations > Users > Edit. For invited users, the flag is granted after the invitee has accepted and created their account.
• Members: everyone else, who use Pass under the organisation's policies.

The More actions menu beside each user offers Change password, Revoke sessions (signs the user out of all sessions) and Delete (removes the user from the organisation). Revoke sessions is the containment step for a suspected account compromise.

Our recommendations for privileged access:

• Two or three admins: enough for cover, few enough to review. Each is a named person, signed in through SSO, with 2FA required.
• Password handover: when you create a user with "Create password instead", Proton asks you to share the password over a secure channel. Use a one-time method and ask the user to change it at first sign-in.
• Vault ownership: because deleting the owner's account deletes the vault for everyone, have team vaults created by a durable owner (an admin or a team lead), and move items to a new vault before a leaver's account is deleted.
• Admin-created vaults: turning off "Allow all users to create vaults" means admins create every vault, which gives a clean, reviewable structure for larger teams.

Integrations, API tokens and service accounts

Two kinds of integration credential exist in a Proton Pass organisation: the SCIM token your IdP uses, and the personal access tokens that scripts use with the CLI.

SCIM provisioning

SCIM requires SAML SSO first. For Entra ID, Proton's guide has you open the existing Proton SSO enterprise application, set Provisioning to Automatic, enter the SCIM base URL as the tenant URL (Proton recommends appending ?aadOptscim062020 for Entra compatibility) and the SCIM token as the secret token, then test and start provisioning. Users and groups assigned to the app are provisioned; invited users accept by email and an admin confirms them in the admin panel. Test removal with a dummy user before relying on it for leavers, and record what your IdP does on unassignment. See the SCIM Provisioning Guide.

CLI personal access tokens

The Proton Pass CLI documentation describes three sign-in paths: interactive web login (which supports SSO, 2FA and hardware security keys), the extra password where an account has one, and a personal access token. A PAT is supplied with PROTON_PASS_PERSONAL_ACCESS_TOKEN (the documented recommendation) or --personal-access-token, is granted access only to the vaults or items you choose, produces sessions that last 2 hours and shows its token name in pass-cli info, which makes it easy to attribute. Secrets are referenced as pass://vault/item/field and injected into applications through environment variables or template files.

A PAT is a non-human identity. Our handling rules: create a dedicated vault per workload, grant the token only that vault, name the token after the workload and owner, store it in the platform's secret store and replace it on a set cycle and whenever its owner changes role. See the Secrets Management Guide for the wider lifecycle.

Logging and detection

The usage log (Admin panel > Proton Pass > Usage log) is available on Proton Pass Professional, Proton Workspace Standard and Proton Workspace Premium with an administrator account. Each entry shows time, user, event type and source IP address, and the log filters by email or IP, event type and date range. Export downloads a CSV that keeps the active filters, which is the route into a SIEM.

Combine the usage log with your IdP's sign-in logs: SSO sign-ins, 2FA challenges and Conditional Access results live there, and joining the two on user and IP gives the fullest picture. During an investigation, revoke the user's sessions first, then review their item reads and shares.

Metrics that show the baseline is working

• 2FA coverage: share of members with 2FA, or signing in through SSO with IdP-enforced MFA (target: 100%).
• Admin count: number of users with the admin flag, reviewed quarterly against the approved list.
• Leaver lag: hours from directory removal to removal from Pass through SCIM.
• External shares: vaults shared with addresses outside the organisation (target: zero, or a named exception list).
• Token hygiene: PATs older than your rotation period, and PATs without a named owner (target: zero).
• Log export cadence: days since the last usage log export reached the SIEM.

Hardening baseline

The policies below are the documented controls; the values are our recommendations. Proton's policy article explains that by default members can export only vaults they created, and the data export policy changes that behaviour, so confirm the exact toggle direction in the current admin panel before rollout.

Phased rollout

1. Inventory: list users with the admin flag, existing shared vaults (use See members on each), any external shares and any PATs in use.
2. Protect admins: require 2FA for administrators and reduce the admin list to two or three named people.
3. Pilot SSO: verify the domain, configure SAML with an IT pilot group, and confirm that members appear under Users after first sign-in.
4. Require 2FA for everyone: send the automated reminder first, give a dated deadline, then switch on the requirement.
5. Apply policies: turn off external sharing and member export, then decide on item sharing and vault creation; record any exceptions. To roll back a policy, switch its toggle back in the same screen.
6. Connect SCIM and logging: enable SCIM, test with a dummy joiner and leaver, then schedule usage log exports to the SIEM.
7. Move automation to scoped PATs: one vault and one token per workload, with an owner and a renewal date.
8. Review quarterly: admins, external shares, vault owners, PAT ages and policy exceptions.

Framework mapping

Common misconfigurations

• Leaving 2FA at the default: the default encourages rather than requires 2FA. Require it, starting with administrators.
• Team vaults owned by individuals who leave: deleting a vault owner's account deletes the vault for everyone. Use durable owners and move items before deleting a leaver.
• External sharing left open: with "Allow sharing outside the organization" on, a member can share a vault key with a personal address. Turn it off and handle real external needs through a named exception.
• A human account used for automation: scripts signed in as a person inherit all of that person's vaults. Use a PAT scoped to one vault.
• PATs in environment files committed to source control: follow Proton's guidance to keep tokens in a secret manager or a mode 600 file, and add pst_ to your secret scanning patterns.
• Usage log never exported: the log is only useful for detection if someone reviews it. Schedule exports and alerts.

Practitioner checklist

• Require 2FA for everyone under Organization > Authentication security.
• Keep two or three named admins, each signing in through SSO.
• Configure SAML SSO on a verified domain and add SCIM for users and groups.
• Turn off sharing outside the organisation and member data export.
• Decide item sharing and vault creation policies by team size and record the decision.
• Give team vaults durable owners and move items before deleting a leaver.
• Issue one scoped PAT per workload, store it in a secret store and replace it on a set cycle.
• Export the usage log to the SIEM and alert on bulk reads, new shares and vault deletion.
• Ask members to set a PIN and short auto-lock; enforce device lock on mobile.

Standards and references

• Proton: Proton Pass security model
• Proton: How to manage team policies
• Proton: Proton Pass for Business admin guide
• Proton: How to set up SSO for Proton Pass
• Proton: How to set up SCIM for Proton Pass using Microsoft Entra ID
• Proton: Pass usage logs for Proton Pass for Business
• Proton: Proton Pass CLI login
• Proton: How to share a vault in Proton Pass

Related NHI Mgmt Group resources: Identity Provider and SSO Security Guide · SCIM Provisioning Guide · Employee Offboarding Security Guide · MFA Guide