Data protection
Three things need protecting: messages moving through the bus, the credentials the platform holds to reach your systems, and the trail both leave behind. This article covers each, in transit, at rest, and over time.
Inbound surfaces are uniform: HTTPS with TLS 1.2. Outbound, transport security is a property of each adapter’s protocol, the platform cannot impose TLS on a protocol that defines its own transport, so the honest answer is a table:
| Surface | Transport security |
|---|---|
| Portal (UI) | HTTPS, TLS 1.2, CORS-restricted. |
| API Listener ingress | HTTPS, TLS 1.2. |
| API adapter, outbound calls | HTTPS, TLS 1.2. |
| SFTP adapter | Encrypted end-to-end by the protocol itself (SSH). |
| Platform-internal traffic (web app to web app) | Private network; never leaves the VNet boundary. |
| SQL adapter | Pending engineering confirmation, see below. |
Authentications, connection strings, API keys, certificates, whatever an adapter needs to reach its endpoint, are written encrypted into the platform database at save time and decrypted only at the moment an adapter resolves the reference at execution. They are never stored readable, and because Authentications are referenced by name from ports, a credential value lives in exactly one place no matter how many ports use it.
The encryption is performed under a platform-managed key held inside the platform’s own data layer, which, like everything else stateful, sits in your tenant, behind your Azure access controls and the database’s own authentication. Isolating this key into a dedicated key store is on the product hardening roadmap. The key for exported material is different, it is yours, not the platform’s, as described below.
The one moment credentials can leave the database is a snapshot that includes Authentications or Constants values. That payload is encrypted in blob storage under a password the operator supplies at creation or export time, the system does not hold it, cannot recover it, and a snapshot file is useless to anyone who obtains it without the password. The open, structural part of a snapshot stays readable; only the sensitive payload is sealed.
Message bodies persist in the TrackingDB according to the tracking level chosen on each port, from errors-only up to full bodies, so the first retention decision is per port: track only what you need. From there, retention windows govern how long tracked runs survive, and the platform’s own maintenance jobs prune anything older on a nightly cycle. Log streams carry their own retention and immutability windows, sized for compliance frameworks and documented in Logs.
Residency follows the deployment: TrackingDB, logs, and snapshots all live on the Azure resources in your subscription and region, as laid out in the Security overview.