Control plane
Customer Azure tenantCerbiShield services, customer governance storage, databases, Dashboard, and evidence live inside the customer deployment rather than a shared Cerbi raw-telemetry SaaS plane.
Security architecture
Make every trust boundary visible before asking for trust.
Cerbi’s security story is strongest when it is concrete: where telemetry flows, where policy is stored, who can change it, how runtime policy is verified, and what evidence remains afterward.
01Trust map
Different Cerbi paths touch different assets.
Scanner, Stream, Gateway, and CerbiShield should not be collapsed into one vague “secure by design” statement. Their trust boundaries are intentionally different.
Customer-controlled zone
Runtime telemetry and governance assets
Telemetry sources
Apps / OTLP
Enforcement
Stream / Gateway
Destinations
Customer tools
CerbiShield
Policy / targets
Customer keys
Signing / verify
Evidence
Audit / records
No shared raw-log relay requirement
The core runtime path is not customer telemetry → Cerbi SaaS → customer destination.
Microsoft identity boundary
Dashboard users authenticate with Microsoft Entra rather than a separate Cerbi password store.
Gateway data plane
Customer Azure tenantGateway receives and forwards selected OTLP traffic inside the customer environment. The customer chooses the ingress source boundary and downstream destination.
In-process path
Application processCerbiStream can execute policy before selected telemetry leaves an application process when app-level integration is the appropriate control.
Discovery path
Repository / CICerbi Scanner moves governance earlier into source and CI without requiring production telemetry to be sent to a Cerbi-hosted runtime service.
02Gateway controls
The network-facing path gets explicit runtime controls.
Gateway security centers on source restriction, policy authenticity, customer-local keys, encrypted transport, and deployment-time rejection of unsafe configuration.
Read the Gateway technical guide01Runtime policy integrityGateway verifies signed Runtime Policy Bundles before applying them.
02Signing keyCustomer-local Azure Key Vault EC P-256 signing material remains non-exportable and is used for sign/verify operations.
03Policy storageCustomer-local Blob storage keeps runtime policy with public access disabled and HTTPS retrieval.
04IngressOTLP/HTTP ingestion is HTTPS-only and is restricted to the customer-approved source CIDR in the deployment contract.
05Downstream transportGateway forwards to the configured OTLP/gRPC destination with TLS enabled.
06Unsafe configurationThe deployment contract rejects invalid or overly broad network settings rather than silently relaxing them.
03Evidence as a security control
A secure runtime is not enough if nobody can explain what changed.
Policy versions, deployment targets, violations, exceptions, and actor context are part of the security story because change control determines whether an enforcement mechanism remains trustworthy over time.
Explore Evidence CenterCerbiShield / Evidence CenterActual Aug 2026 preview
04Operational security
Security is also identity, change control, and observable health.
The governance plane should be reviewable as an operating system, not trusted as a black box.
Identity
Microsoft Entra authentication for Dashboard access and bearer-token validation across platform APIs.
RBAC
Role-aware control surfaces separate administration, policy authoring, deployment, operation, audit, and read access.
Change history
Policy and deployment workflows retain actor, version, target, state, and timestamp context.
Validation
Representative payloads and rules can be checked before changing a selected enforcement boundary.
Targeting
Governance policy can be associated with explicit workloads and environments rather than relying on one invisible global rule set.
Health
Service and routing health remain visible so the governance plane is not treated as opaque infrastructure.
05Path-specific posture
Repository / CI
Scanner
Move governance left without runtime traffic.
Discovery runs against source and build context so teams can identify risky logging before production telemetry exists.
Application process
CerbiStream
Move the boundary closest to emission.
Use application integration where preventing the first network hop is the control requirement that matters most.
Customer OTLP path
Gateway
Centralize enforcement for existing emitters.
Use a customer-hosted OTLP boundary when estate-wide adoption friction matters more than application-local execution.
Claims we intentionally do not make.
Trust gets weaker when architecture controls are translated into blanket certification or availability promises.
01
Installing CerbiShield does not make an organization automatically compliant with HIPAA, PCI DSS, SOC 2, GDPR, ISO 27001, FedRAMP, or another framework.
02
Compliance-oriented templates, signatures, policy records, and evidence are controls and review aids, not certifications or legal determinations.
03
CerbiStream benchmark results do not automatically apply to Cerbi Gateway; each runtime path requires its own reproducible evidence.
04
Preview or release-candidate functionality is not described as generally available until its corresponding release gates are complete.
Review the boundary
Security review should start from your actual telemetry path.
Bring the applications, OTLP topology, network constraints, identity model, and downstream destination you already use. Then decide which governance boundary is justified.