Canopy holds your authentication, your identities, and your authorization logic. We apply the same rigor to our own platform that we give you: modern credential protection, strong MFA and enterprise SSO, strict tenant isolation, encrypted secrets, and comprehensive auditing. Every claim below is something your security team can verify.
How login is protected for both administrators and your end-user identities.
Passwords are hashed with Argon2id (the OWASP-recommended memory-hard algorithm), combined with a server-side pepper held separately from the database. Plaintext passwords are never stored or logged.
Repeated failed logins trigger progressive account lockout with increasing delays on both surfaces, and administrator accounts additionally enforce password history to prevent reuse of recent credentials.
Refresh tokens are single-use and rotated, with every token chained to its successor. Replaying a stolen token revokes the entire token family, while harmless browser races (two tabs refreshing at once) are recognized and kept signed in. Theft gets a hard response; your users don't get false logouts.
CAPTCHA challenges protect login and self-service signup against credential stuffing and automated abuse.
Canopy-hosted login is protected with CSRF tokens and sealed session cookies (HttpOnly, Secure, and SameSite), so tokens are never exposed to client-side script.
Multiple second factors, enforceable per environment, with step-up for sensitive operations.
Second factors include TOTP authenticator apps, WebAuthn passkeys and hardware security keys, email one-time passcodes, and single-use recovery codes.
MFA can be required per environment, with configurable grace periods so teams can roll it out without locking users out mid-transition.
Sensitive operations can require fresh step-up verification. Admin-assisted recovery restores access for lost devices without weakening the factor model.
Identity federation and lifecycle automation: a security control and an offboarding capability.
Federate both administrators and your end users through SAML 2.0 or OIDC against your identity provider.
SCIM 2.0 syncs users from your directory with group-to-role mapping. When someone leaves your IdP, access is revoked automatically, closing the offboarding gap reviewers care about.
A three-tier boundary that keeps blast radius contained. Authorization data is strictly environment-scoped.
A development credential cannot reach production data. API keys are bound to a single environment, and cross-tenant or cross-environment access attempts are actively rejected, not merely filtered.
How integrations authenticate, how tokens are verified, and what is encrypted, stated precisely.
Access tokens are JWTs signed with RS256. A public JWKS endpoint lets your services verify tokens independently, without sharing a secret. Signing keys are isolated and rotatable.
The authorization-code flow requires PKCE, mitigating authorization-code interception. Access tokens are short-lived and refreshed via rotation.
Each API key is scoped to a single environment and a defined set of permissions. A leaked key can never act outside its environment.
All traffic (API, applications, and webhooks) is served over HTTPS/TLS. Plaintext connections are not accepted.
Sensitive stored secrets (MFA/TOTP seeds and OIDC client secrets) are encrypted with AES-256-GCM. Platform secrets live in an encrypted secret store, never in code or config, and signing keys are isolated from application data.
Primary data is hosted on reputable managed infrastructure. We describe the exact at-rest posture of the datastore in our security documentation, available on request for your review, rather than asserting a blanket guarantee here.
How permission decisions reach your app, what that costs in freshness, and where a refresh token lives on each kind of client.
Our SDK asks where an identity may act (the nodes each permission was granted at) rather than asking about one node per request. Checks are then answered locally by walking your hierarchy, so Canopy is not in the path of every authorization decision your app makes.
Grant roots and the hierarchy are held for at most 60 seconds, so an access change (including a moved node) takes effect within a minute. A revoked user can still act until then. Set the window to zero to read fresh on every check, at the cost of a round trip per request. We state the ceiling plainly because your access-review process needs the number, not a reassurance.
Browser apps get an httpOnly cookie page scripts cannot read. Installed mobile apps, which have no cookie jar, get the token in the response body to store in the OS keychain. Which one you get follows the publishable key you registered, never a request parameter, so a compromised web app cannot ask for the token the cookie exists to hide.
A session records how it delivers its refresh token when it is created and keeps that through every rotation. The refresh endpoint accepts no key at all, so there is no parameter with which to talk a browser session into handing its token to a script.
A comprehensive, tamper-evident trail: customer-facing forensics and internal accountability.
Every security-sensitive event is recorded against a typed catalog and scoped across account, application, and environment, so you can answer exactly who did what, where.
Correlation IDs let you reconstruct a full request across services. Snapshot labels preserve the human-readable context of an action even after the underlying entity is deleted.
Reads of the audit log are themselves logged. Access to the forensic record is part of the forensic record.
How the platform is run, described at the level that's true of the real deployment.
In production, the service refuses to start if critical security configuration (signing keys, secret pepper, encryption keys) is missing. Misconfiguration fails loudly at boot rather than silently degrading.
Cross-origin access is restricted to explicitly allowlisted origins: no wildcard origins in production.
Development and production run as isolated environments with separate secrets and data. Reputable managed infrastructure backs the database, cache, and object storage.
Found something? We want to hear from you, and we'll work with you in good faith.
If you believe you've found a security vulnerability in Canopy, report it directly to our security team. We commit to acknowledging your report, keeping you updated, and not pursuing legal action against good-faith research that respects the scope below.
The Canopy API, hosted authentication, our applications, and official SDKs.
Denial-of-service, social engineering, and physical attacks. Don't access other tenants' data.
Acknowledgement within a few business days, and coordinated disclosure once a fix ships.
We state only what's real.
Canopy is early-stage, and we don't claim certifications we haven't earned. You won't see a compliance badge here until an audit is actually complete. Formal compliance work, including SOC 2, is on our roadmap. If your security review needs specifics (how we handle and process data, who our subprocessors are, or a completed security questionnaire), contact our team and we'll share what we can.