Cerby · Trust Center

Cerby Trust Center

Trust center

Cerby maintains a public trust center covering its security and compliance posture.

IdentityAccess ManagementSecurityPassword ManagementProvisioningSCIMIdentity GovernanceNonfederated ApplicationsAutomationWebhooks
Trust center: https://trust.cerby.com/

Certifications & Compliance

Source

Trust Center

cerby-trust-center.yml Raw ↑
generated: '2026-08-09'
method: probed
probe: true
url: https://trust.cerby.com/
exists: true
contents_readable: false
platform: Drata
platform_evidence:
  dns: trust.cerby.com CNAME trust.cname.drata.com
  detail: >-
    trust.cerby.com is a genuinely provisioned host, not the *.cerby.com
    wildcard. Control probe: zzznotreal.cerby.com returns HTTP 200 from an AWS
    origin identifying itself as "server: banana", while trust.cerby.com returns
    HTTP 403 from Cloudflare with a challenge ray and CNAMEs to Drata's trust
    center service. Different origin, different response — the trust center is
    real.
access:
  http_status: 403
  reason: Cloudflare interactive bot challenge ("Just a moment... Enable JavaScript and cookies to continue")
  browser_ua_retried: true
  outcome: >-
    The certification list could not be read. Cerby's own attestations, if any,
    live behind this challenge.
certifications: []
certifications_note: >-
  DELIBERATELY EMPTY. No certification is attributed to Cerby because none could
  be verified. This is the trap on this provider and it is worth stating plainly:
  https://www.cerby.com/security returns 200 and does name SOC 2 Type I, SOC 2
  Type II and ISO 27001 — but its section 1 is titled "CLOUD PROVIDER's Audits &
  Certifications", and section 1.1 reads "Cerby currently relies on its Cloud
  Provider's third-party reviewed Security Program". Section 1.3 goes further:
  "To the extent Cerby does not obtain a Third-Party Audit of its own, Cerby will
  adopt or maintain ... an equivalent, industry-recognized framework" — the
  document explicitly contemplates Cerby having no audit of its own. Harvesting
  those certification names would attribute a subprocessor's attestations to
  Cerby. They are recorded below as what they are.
cloud_provider_requirements_published:
  relied_on_by_cerby: [SOC 2 Type I]
  required_of_cloud_providers: [SOC 2 Type II, ISO 27001]
  attributed_to: Cerby's cloud provider, NOT Cerby
  source: https://www.cerby.com/security
security_policy:
  url: https://www.cerby.com/security
  title: Security Policy | Cerby
  type: contractual security addendum
  http_status: 200
  published_commitments:
  - Customer Data encrypted at rest with AES 256-bit or better.
  - TLS 1.2 or better for Customer Data in transit over untrusted networks.
  - Encryption keys logically separated from Customer Data.
  - Customer Data hosted in the United States production cloud environment, or another mutually agreed region.
  - Critical and high vulnerabilities addressed within 30 days, medium within 90 days, on commercially reasonable efforts.
x-evidence:
- url: https://trust.cerby.com/
  http_status: 403
  fetched: '2026-08-09'
- url: https://www.cerby.com/security
  http_status: 200
  fetched: '2026-08-09'
- url: https://zzznotreal.cerby.com/
  http_status: 200
  fetched: '2026-08-09'
  role: false-positive control