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:

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 the owning Application, from errors-only up to full bodies, so the first retention decision is per Application: track only what you need. That decision covers every port the Application owns, which makes it a blunter instrument than a per-port choice would be. If one flow inside an Application handles payloads you would rather not persist, the level has to come down for all of them, or that flow has to live in its own Application. From there, two things govern how long a tracked run survives. The first is the retention window: the platform’s own maintenance jobs prune anything older on a nightly cycle. The second is the lifecycle of the owning Application: tracked runs belong to the Application whose ports recorded them, and deleting that Application deletes all of its tracking data at once, whatever its age. That deletion is permanent and there is no restore path, because a snapshot captures configuration and has never contained tracking history. Only an Application Owner can delete an Application, and the deletion is itself an audited event. Log streams carry their own retention and immutability windows, sized for compliance frameworks and documented in Logs, and they are not part of the Application, so they survive its deletion.

Deletion reaches the overflow blobs too. Message bodies too large for the TrackingDB are written to the Storage account instead, and those blobs belong to the Application the same way the tracking rows do. Deleting an Application removes both: the tracking rows in the database and the overflow message bodies in Storage. Nothing of the tracked history survives in either place.

There is no tracking export. Art2link ESB provides no way to export tracking data, in any format, and none is planned. Combined with the two governors above, that means tracked history cannot be preserved outside the platform before the retention window prunes it or the owning Application is deleted. Tracked runs are read on the Tracking screen and nowhere else, so the history exists for exactly as long as those two governors allow and no longer.

Residency follows the deployment: TrackingDB, the Storage account, logs, and snapshots all live on the Azure resources in your subscription and region, as laid out in the Security overview. Deleting an Application removes its tracking data in place; nothing is copied anywhere else first.