How Attryn secures communication, access, and customer data

This page describes the security technologies used in the Attryn web application and public website. It is intended to help customers, security reviewers, and procurement teams understand the architecture without exposing secrets, credentials, or customer-specific configuration.

The public website and the authenticated application are separate surfaces. The website provides product information and policy pages, while the authenticated application uses additional access control, session, audit, and tenant-isolation controls for customer data.

Attryn is designed to be served over HTTPS and applies browser-side protections intended to reduce common web attack surfaces such as unsafe framing, overly permissive content execution, and insecure handling of authenticated responses.

The platform also applies request-handling and response-handling controls that support abuse detection, conservative caching behavior for authenticated traffic, and safer operation behind a managed edge or reverse proxy.

Attryn supports credentials-based access and enterprise single sign-on through OpenID Connect providers such as Okta and Microsoft Azure AD, depending on deployment configuration.

For credentials-based access, passwords are hashed with Argon2id. Registration can be constrained through controlled onboarding flows, and authentication endpoints are protected with stricter abuse controls than general application traffic.

Active sessions can be reviewed and revoked through administrative controls so organizations can respond quickly when access needs to be withdrawn.

Customer data is modeled around explicit organization boundaries so each tenant operates within its own application and data context.

Attryn uses PostgreSQL row-level security together with request-scoped tenant context to enforce read and write isolation in the database layer, not only in application code.

This means the platform is designed so cross-organization access is blocked by the underlying data layer as well as by role-aware application logic.

Sensitive fields are protected with application-layer encryption using AES-256-GCM before storage, reducing exposure if raw storage contents are accessed outside normal application pathways.

Where selected matching operations are needed, Attryn uses deterministic blind-index techniques so those lookups do not depend on storing searchable plaintext values.

Encryption keys and authentication secrets are supplied through runtime configuration in production rather than embedded in source control. Operational logging is also designed to redact sensitive values.

Attryn applies operational controls for rate limiting, session review and revocation, and safer handling of authentication-related traffic. Authentication flows use more restrictive abuse controls than general application requests.

The platform records audit events for security-relevant actions such as successful and failed authentication, sign-out, session revocation, and IP whitelist changes. Audit records are maintained with organization scoping, and support workflows use request traceability without exposing internal stack traces to end users.

Organizations can also enable IP allowlisting controls in the admin layer when they want access restricted to approved networks or ranges.

Compared with many planning and resourcing tools, Attryn places tenant segregation directly in the database layer through organization-scoped schemas, session-bound tenant context, and PostgreSQL row-level security. In practice, that gives cross-organization isolation a stronger technical boundary than products that rely primarily on application-level workspace filtering.

Compared with larger enterprise incumbents, Attryn already covers the core controls buyers usually expect in this category: encrypted transport, enterprise SSO options, strong password hashing, session revocation, audit logging, IP allowlisting, rate limiting, and protection of sensitive fields with application-layer encryption.

Where larger platforms may still present a broader public security package is in externally published assurance programs, formal compliance attestations, and adjacent governance features. Attryn's current strength is the underlying architecture and segregation model; its public assurance surface can continue to expand over time.

The production architecture separates the application, database, cache, and supporting operational components so they do not all share the same runtime boundary.

Data stores and supporting services are intended to sit behind controlled application ingress rather than being treated as broadly exposed public endpoints. This reduces attack surface and supports a more defensible deployment model.