Authentication and access controls

HelmXP's authentication system is built from the ground up — no third-party auth provider. Every sign-in method, session, MFA challenge, and role check runs in HelmXP's own code, giving HelmXP full control over the security posture.

Sign-in methods

Email and password

Available on all plans. Passwords are hashed with Argon2id and a per-account salt. Plaintext passwords are never stored or logged.

Magic link (passwordless)

A one-time sign-in link sent to the user's email address. Valid for 15 minutes, single-use. This is the recommended sign-in method for Captains (board members), who often prefer not to manage passwords.

SAML 2.0 SSO

Available on Growth and Enterprise plans. HelmXP acts as a SAML 2.0 Service Provider. Supported Identity Providers include Okta, Microsoft Entra ID, and Google Workspace. Any SAML 2.0-compliant IdP will work.

SAML SSO is configured per-Hub by the CEO Seat from the Hub's admin section. See your portal's help section for setup instructions after signing up.

SCIM 2.0 provisioning

Available on Growth and Enterprise plans. SCIM lets your identity provider automatically provision and de-provision Seats as staff join or leave. New Seats are created in HelmXP when your IdP pushes a SCIM Create event; Seats are deactivated (not deleted) when your IdP pushes a SCIM Delete event.

Multi-factor authentication

HelmXP supports TOTP (time-based one-time password) via any standard authenticator app (Google Authenticator, 1Password, Authy, Microsoft Authenticator). Hardware security keys (WebAuthn/FIDO2) are on the v2 roadmap.

Recovery codes are generated at MFA enrollment — 8 single-use codes, downloadable as a text file. Lost recovery codes can be reset by the CEO Seat from the Hub's admin section.

Session management

• Sessions are stored in the PostgreSQL database, not in client-side cookies
• Session tokens are signed with HMAC-SHA256; the signing key is held in the environment, not in the database
• Sessions expire after 30 days of inactivity and on sign-out
• Signing in from a new device does not invalidate sessions on other devices
• The CEO Seat can invalidate all sessions for any Seat from the Hub's admin section

Role-based access

HelmXP enforces a strict role hierarchy. Each role has an explicit permission set:

Role boundaries are enforced at the server side on every request. A Sub-seat cannot approve a section even if they modify the request directly — the server checks the session's role before writing.

Brute-force protection

Failed sign-in attempts trigger a progressive lockout:

• 5 consecutive failures: 15-minute account lock
• 10 consecutive failures: 1-hour account lock
• 20 consecutive failures: account locked until CEO Seat or HelmXP support unlocks it

Lockout thresholds apply per email address, not per IP address. IP-based rate limiting is applied separately at the CDN layer.

Audit trail for authentication events

Every authentication event is written to the Logbook:

• Successful sign-in (method, device type, IP region)
• Failed sign-in attempts
• MFA enrollment and de-enrollment
• Password changes
• Session invalidation
• SAML assertion receipts and SCIM provisioning events

Authentication Logbook entries are retained for 7 years.

See also

• [[helmxp-security-overview]] — full security posture overview
• [[how-your-hubs-data-is-isolated]] — tenant isolation architecture
• [[adding-seats]] — inviting executives and assigning roles to Seats