Security posture

This page summarises CDC’s security stance at the altitude a technical evaluator needs to judge it against an organisation’s security bar. It covers the platform’s default posture, the trust boundaries, and the controls around identity, access, secrets, and data. Two companion pages go deeper on the areas that most often draw scrutiny: identity and authentication and the secrets posture.

Default-deny, no unauthenticated mode

CDC has no unauthenticated mode. Both the management API and the public integration surface require a validated identity; there is no configuration switch that turns authentication off. The hosts fail fast at startup if the authentication configuration is absent: an operator cannot accidentally deploy CDC open to the network.

Authorisation is default-deny: a global fallback policy closes every endpoint that has not explicitly declared its access requirement. A newly added surface is closed until someone deliberately opens it, rather than open until someone remembers to close it. The only anonymous surfaces are the health probe, the single-page-app’s static assets, and a public-API wildcard that enforces its own per-route requirement as data, so even the “open” path is governed by an explicit author decision, not by omission.

Trust boundaries

An evaluator should reason about four boundaries:

• Caller → platform. Every external caller (an interactive user, a machine client, or a webhook) presents a bearer token that the hosts validate as resource servers (issuer and a dedicated API audience both checked). Identity is never inferred from network position.
• Engine → Master. The only channel between a remote engine and the Master is the internal message broker, one transport to secure and monitor, with no separate engine-to-Master HTTP path to lock down. Engines hold no direct database credentials.
• Platform → source and consumer systems. Integrations run through plugins whose credentials are held in the secret store, never in process definitions or configuration files. What a consumer may read is decided at the governed egress boundary, not left to the consumer.
• Operator → secret store. Secrets can be written and overwritten but never read back through the API, so an authenticated operator cannot exfiltrate the values CDC holds. See the secrets posture.

Identity and access

Access is expressed as a flat scope vocabulary: one read and one write scope per functional area, plus a handful of fixed-purpose scopes. Users receive scopes only through group membership (no ad-hoc per-user grants), and machine clients receive them through their service accounts, so an evaluator can reason about “who can do what” through group design rather than a sprawl of individual permissions. An authenticated caller missing the required scope is refused with a clear authorisation error, distinct from the no-token case.

The platform can either use its own identity provider or broker sign-in to a corporate directory (for example Microsoft Entra ID), so a customer’s existing identity governance (accounts, group membership, joiner/mover/leaver) remains the source of truth. The identity and authentication page covers the model, the scope vocabulary, and the brokering posture in full.

Data protection

• Sensitive fields are declared, then enforced. Model properties marked sensitive are masked in logs and the UI; properties marked encrypted are protected in transit and at rest. Classification is a model fact, so the same rule applies everywhere the data moves (see the governed domain models page).
• Egress is a decision, not a read. What a consumer receives passes through the governed egress boundary, where ownership, sovereignty, masking, and policy materialise into the permitted view. A read is never a raw dump of the store.
• Region containment fails closed. An engine only ever processes data for regions it is authorised for, enforced both by the Master’s distribution gate and by the engine’s own fail-closed check: a single misconfiguration cannot move regulated data out of its allowed region.
• The audit trail is tamper-evident. Audit records are chained at record level, so any alteration or reordering is detectable. This is covered in the governance and audit model.

Accountability

Every governed operation resolves to a real principal (the authenticated caller, or an explicit system identity for timer- and message-triggered work), captured immutably at the start of a process instance and written into the audit trail alongside the process that ran. Automated agents act on behalf of the conversing user or a process’s captured principal and never hold standing data-access identity of their own. There is no “the platform did it” in the audit record; there is always a who.

What to take into an evaluation

• Authentication is mandatory and fails safe; there is no open mode.
• Authorisation is default-deny with a small, group-granted scope model.
• Identity can be brokered to a corporate directory, keeping identity governance where it already lives.
• Secrets are write-only through the API; classification and region rules are enforced at the boundaries and fail closed.
• Every action is attributable to a real principal in a tamper-evident trail.

The identity and authentication and secrets posture pages expand the two areas that most security reviews probe hardest.