Security Overview

How we protect customer data, including PHI, across the Credentik platform. We aim for transparency here so your security team can evaluate us without a sales call.

Authentication and access

• Passwords are hashed with bcrypt (cost factor 12). Plain-text passwords are never stored or transmitted.
• Sanctum-based JWTs for API authentication; tokens scoped per device and revocable from the user profile.
• Role-based access control: superadmin, owner, agency, staff, organization, provider, auditor — with middleware-enforced gates on dangerous endpoints (write-offs over $500, bulk actions, tenant data deletion).
• Custom roles with granular, least-privilege permissions for staff users (for example billing-only or read-only credentialing), defined per agency.
• Multi-factor authentication (TOTP) available on the user profile; agency owners can require it for their whole team.
• Single sign-on (Growth plan) with Microsoft Entra ID, Google Workspace, Okta or any OpenID Connect or SAML 2.0 identity provider. Agencies can require SSO for everyone except owners.
• Delegation auditor access for health-plan auditors is read-only, limited to the files in the audit's scope, and expires when the engagement ends.
• All authentication events (login, failure, MFA challenge, password reset) logged with IP and user-agent.

Tenant isolation

Credentik is a multi-tenant SaaS. Every data row carries an agency_id and every query is filtered through a global Eloquent scope (BelongsToAgency + TenantScope). Cross-tenant data exposure is prevented at the ORM layer, not just the application layer. Superadmin access to a tenant is logged with the impersonator's user id on every write.

Encryption

• In transit: TLS 1.2+ for all connections (app, API, database). HSTS enforced on credentik.com and app.credentik.com.
• At rest: Google Cloud SQL (PostgreSQL) and Cloud Storage encrypt all data at rest; patient identifiers (names, dates of birth, member IDs, contact details) and message bodies are additionally field-level encrypted by the application.
• Sensitive credentials (clearinghouse, payer API keys) are field-level encrypted using Laravel's encrypted casts (AES-256-CBC with per-app key).

Audit logging

Every model write that touches PHI passes through our Auditable trait, which records the user, timestamp, IP, user-agent, old values, new values, and (for superadmin operations) the impersonator. Audit logs are retained for the life of the account plus 7 years.

PHI access logging

• Views, lists, downloads and exports of patient information through the application are written to an append-only PHI access log: who, their role, what action, which record, how many records, when, and from which IP address. The log itself holds no PHI; patients are identified by a keyed hash.
• Agency admins can see who accessed a patient's record and export the log.
• An hourly check flags unusual access, such as high volume, after-hours activity, large exports or access by a deactivated user, and alerts the agency's owners and admins in the app and by email.

Email delivery log

Every email the platform sends is recorded with its template, recipient, subject, delivery status and timestamps. Message bodies are not stored in the log. Bounced and complaint addresses are flagged so admins can follow up.

Data export and offboarding

• Return: the agency owner can request a full export of the agency's data and documents, delivered with a checksummed manifest.
• Destroy: deletion is scheduled with a grace period and runs against a documented, per-table disposition. When it completes, the customer receives a destruction certificate.
• Retain: only records that must be kept for a legal retention period are retained (audit logs: the life of the account plus 7 years), and they are purged automatically when that period ends.

Backups and disaster recovery

• Google Cloud SQL automated backups every 24 hours, retained 14 days, plus point-in-time recovery (7-day window).
• Uploaded documents are stored in a private, versioned Cloud Storage bucket in the United States (us-east1).
• Recovery objectives: RPO < 24h, RTO < 4h for the production database.

Incident response

Our incident-response process follows a four-phase model: detect → contain → eradicate → recover. For security incidents involving PHI we notify affected agencies' designated security contacts within 60 days of discovery, in accordance with 45 CFR 164.410, with the information required to enable downstream HIPAA Breach Notification Rule compliance.

Report a suspected incident to security@credentik.com.

Subprocessors

We use the following subprocessors. Each is bound by a Data Processing Addendum and, where PHI is involved, a Business Associate Agreement.

Responsible disclosure

If you've discovered a security vulnerability, please email security@credentik.com with details. We will respond within two business days and aim to remediate confirmed issues within 30 days. We do not currently run a paid bug bounty but we acknowledge contributors in our security hall of fame.

Compliance posture

Credentik is built to support HIPAA-covered agency workflows. We are not currently SOC 2 certified; a SOC 2 Type I audit is on the 2026 roadmap. For agency security questionnaires, please email security@credentik.com — we maintain a standard answer set and can return most questionnaires within five business days.