Security & SSO

PurpletGo provides enterprise-grade security controls including SAML SSO, multi-factor authentication, IP allowlisting, and SIEM integration.

SAML Single Sign-On

PurpletGo supports SAML 2.0 SSO, available on the Team and Enterprise plans. It works with any SAML 2.0-compliant identity provider - Okta, Azure AD / Microsoft Entra, Google Workspace, and others that speak the standard.

Setting up SAML SSO

1. Go to Settings → Security → SAML SSO. Only a Super Admin can view or change SSO settings, in the app and through the API. Whoever controls the identity provider configuration can sign in as any member of the organisation, so this is not delegated to Admins or custom roles.
2. Copy the ACS URL, SP Entity ID, and SLO URL shown there - your IdP will ask for these.
3. In PurpletGo, provide your IdP's metadata: either paste its metadata XML, give PurpletGo an HTTPS URL to fetch it from, or enter the IdP entity ID, SSO URL, and certificate manually.
4. Choose whether new users should be created automatically the first time they sign in via SSO (JIT provisioning), and what role they get by default. You can also map SAML group membership to specific PurpletGo roles.
5. Save. If you're using the metadata-URL option, a Test button appears before saving so you can confirm PurpletGo can reach the URL. The metadata URL must answer directly - PurpletGo does not follow redirects when it fetches it.

PurpletGo never sends a stored metadata XML document or IdP certificate back to the browser. When one is stored, the field says so - leave it blank to keep the stored value, or paste a new one to replace it. You can change other settings (JIT provisioning, role mapping) without pasting them again.

Every save and removal of the SSO configuration is recorded in the audit log (saml_config.created, saml_config.updated, saml_config.deleted).

Enforcing SSO

You don't have to force everyone onto SSO - Enforce SSO is a separate toggle from having SAML configured at all. When it is on, password login is blocked for every member. To make sure enforcement can't lock your organisation out, PurpletGo only accepts it when:

• an emergency bypass code exists - generate it first (below), and store it somewhere safe, and
• the identity provider configuration actually loads: the metadata parses (or the metadata URL can be fetched), and it has an entity ID, a single sign-on URL and a valid signing certificate.

Turning SAML SSO off also turns enforcement off.

Emergency bypass code

A Super Admin can generate an emergency bypass code, shown once, in case the identity provider breaks while SSO is enforced. With it, a Super Admin can sign in with their password (and 2FA, if they use it) plus the code. The code works once: signing in with it clears it (recorded in the audit log as sso_bypass_code_consumed), so generate a new one straight afterwards.

Roles from your identity provider

With group-to-role mapping, PurpletGo sets a member's role from their IdP groups each time they sign in. Two limits apply: a Super Admin's role is never changed by group mapping, and no group can map to Super Admin. Super Admins can still sign in through SSO as normal.

Once a user signs in via SSO for the first time (with JIT enabled), PurpletGo either links them to an existing account with the same email or creates a new one - it never asks that user to set a password, since they'll always come in through the IdP.

Two-Factor Authentication (2FA)

Any PurpletGo user can turn on TOTP-based 2FA for their own account:

1. Go to your Profile and click Enable 2FA - it's a card directly on the Profile page, not a separate "Security" sub-tab.
2. Scan the QR code with an authenticator app (Google Authenticator, Authy, 1Password, etc.), or enter the secret manually.
3. Enter the 6-digit code it generates to confirm and activate 2FA.

Once enabled, a valid code is required on every login, on top of your password. Disabling 2FA requires both your current password and a valid code from your authenticator - there are no backup/recovery codes, and there's no admin override to force-disable 2FA on someone else's account, so keep your authenticator app backed up.

Requiring 2FA for your organization

A Super Admin can turn on Require two-factor authentication under Settings → Security, on every plan. It is off until someone turns it on. It applies to members who sign in with a password or Google; members who sign in with single sign-on are not affected, because your identity provider handles their second factor.

Each member without 2FA gets a grace period to set it up (none, 3, 7, 14 or 30 days; 7 by default), counted from when the requirement was turned on or from when they joined, whichever is later. Until then they see a reminder with the date. After it, they can only open their Profile until they set up 2FA there; everything else answers with a message saying so. Turning it off asks for your password again (and your 2FA code, if you use one), and every other Super Admin gets a notice in PurpletGo and an email saying who turned it off. Turning it on, turning it off and the grace period chosen are all recorded in the audit log.

PurpletGo support access

PurpletGo support can't see your members, your audit log or your offboardings unless you allow it. A Super Admin allows it under Settings → Security → PurpletGo support access, on every plan:

1. Choose how long: 4 hours, 24 hours or 3 days. Add a reason if you like, such as the support ticket number.
2. Click Allow access and confirm with your password (and 2FA code, if you use it).

Access ends on its own at the time shown, or when you click Revoke access. While it lasts, every look by PurpletGo support is in your audit log as Viewed By PurpletGo Support, with the name of the person and what they saw. In your audit log, support sees what was done but not the people it was done to: their details show as [personal data]. Changes PurpletGo makes to your account without needing your permission, such as your plan, a trial extension, a suspension or a deletion you asked for, are in your audit log too, as Account Changed By PurpletGo. The page lists recent access, who allowed it and who revoked it.

IP allowlisting and geo-blocking

Under Settings → Security → Access Controls you can restrict access by network. Only a Super Admin can view or change these controls, in the app and through the API:

• IP allowlist - a list of IPs or CIDR ranges (up to 100 entries). Once set, any request from an address outside the list is rejected with a 403.
• Blocked countries - a list of ISO country codes (up to 50) to deny outright, based on the request's geolocated country.

Both apply to signed-in members and to API keys. They don't apply to the self-service portal, which departing employees open from their own networks: its private link and one-time code protect it instead.

The page shows Your current IP - the address PurpletGo sees for you - with an Add my IP button.

Session management

• Sessions are valid for at most 7 days from login, based on the age of the session token.
• Sessions also have an idle timeout: a member who has not used PurpletGo for 12 hours (the default) is signed out and must sign in again. A Super Admin can set it anywhere from 15 minutes to 24 hours from Settings → Security, on every plan. It applies to every sign-in method, including single sign-on. A session is checked on each request, so it can last up to a minute longer than the limit. When it happens, the sign-in page says you were signed out due to inactivity. The self-service portal for departing employees keeps its own rule (30 minutes idle, 12 hours at most).
• SSO sign-ins are rate limited per IP address, with separate allowances for starting a sign-in and for completing it, set high enough for a whole office signing in from one shared address.
• An org can additionally set a session timeout (1-8,760 hours) that caps how long any session stays valid regardless of the 7-day default, and terminate every active session org-wide from Settings → Security (a rate-limited "panic button" for Admins and Super Admins).
• Removing a member from the organization, and deprovisioning a person through SCIM, sign them out everywhere: every session of the account is revoked, and the audit log records how many.
• Each user can view and revoke their own active sessions from a card directly on the Profile page. The IP address shown for a session is the one PurpletGo's load balancer saw, not a value the browser can set. The Revoke all sessions button revokes every session for the account, including the one you're currently using - you'll be signed out too, not just your other devices.
• Session tokens are stored in HttpOnly cookies, not accessible to JavaScript.

SIEM export

Enterprise customers can stream every audit log event to Splunk, Datadog, Elasticsearch, Sumo Logic, New Relic, or a generic HTTP endpoint, as JSON or CEF, with retries over more than two days. See SIEM Integration for setup and the events forwarded.

How sensitive data is protected

• Passwords are hashed with bcrypt - never stored or logged in plain text.
• TOTP (2FA) secrets are encrypted at rest with AES-256-GCM.
• API keys are stored as a SHA-256 hash of the raw key; the raw value is shown once, at creation, and never again.
• Audit log entries are chained with HMAC-SHA256, so altering or deleting a past entry breaks the chain, and verifying the chain detects it. PurpletGo's servers run the full check (an admin can start it from the audit log page), because the chain is keyed with a PurpletGo secret. You can check an export yourself without it: exports and the chain's hourly anchors are signed with Ed25519, and the download carries the public key and the steps (Audit Log). The log records changes, sign-ins, exports and report downloads, and access revocations, not every time data is viewed.
• Personal details of departing employees in audit log entries (names, contact details, IP addresses, browser details, notes) are encrypted with AES-256-GCM under a key for each person's records. Erasing the person destroys the key, so the details can no longer be read in PurpletGo or its audit archives, while the entries and the chain stay. See Data Retention: the audit log.

Responsible disclosure

Found a security vulnerability? Please report it to security@purpletgo.com. We acknowledge reports within 24 hours, and fix or mitigate a confirmed critical issue within 72 hours of confirming it. The Vulnerability Disclosure Policy says what to include, the rules for testing, what is in scope, and the safe harbor for good-faith research.