Data encryption in Adobe Experience Platform
Adobe Experience Platform is a powerful and extensible system that centralizes and standardizes customer experience data across enterprise solutions. All data used by Experience Platform is encrypted in transit and at rest to keep your data secure. This document describes Experience Platform’s encryption processes at a high level.
The following process flow diagram illustrates how Experience Platform ingests, encrypts, and persists data:
Data in transit in-transit
All data in transit between Experience Platform and any external component is conducted over secure, encrypted connections using HTTPS TLS v1.2.
In general, data is brought into Experience Platform in three ways:
- Data collection capabilities allow websites and mobile applications to send data to the Experience Platform Edge Network for staging and preparation for ingestion.
- Source connectors stream data directly to Experience Platform from Adobe Experience Cloud applications and other enterprise data sources.
- Non-Adobe ETL (extract, transform, load) tools send data to the batch ingestion API for consumption.
After data has been brought into the system and encrypted at rest, Experience Platform services enrich and export the data in the following ways:
- Destinations allow you to activate data to Adobe applications and partner applications.
- Native Experience Platform applications such as Customer Journey Analytics and Adobe Journey Optimizer can also make use of the data.
mTLS protocol support mtls-protocol-support
You can now use Mutual Transport Layer Security (mTLS) to ensure enhanced security in outbound connections to the HTTP API destination and Adobe Journey Optimizer custom actions. mTLS is an end-to-end security method for mutual authentication that ensures that both parties sharing information are who they claim to be before data is shared. mTLS includes an additional step compared to TLS, in which the server also asks for the client’s certificate and verifies it at their end.
If you want to use mTLS with Adobe Journey Optimizer custom actions and Experience Platform HTTP API destination workflows, the server address you put into the Adobe Journey Optimizer customer action UI or the Destinations UI must have TLS protocols disabled and only mTLS enabled. If the TLS 1.2 protocol is still enabled on that endpoint, no certificate is sent for the client authentication. This means that to use mTLS with these workflows, your “receiving” server endpoint must be an mTLS only enabled connection endpoint.
Download certificates download-certificates
Direct download links for public mTLS certificates are no longer provided. Instead, use the public certificate endpoint to retrieve certificates. This is the only supported method for accessing current public certificates. It ensures that you always receive valid, up-to-date certificates for your integrations.
Integrations that rely on certificate-based encryption must update their workflows to support automated certificate retrieval using the API. Relying on static links or manual updates may result in the use of expired or revoked certificates, leading to failed integrations.
Certificate lifecycle automation certificate-lifecycle-automation
Adobe now automates the certificate lifecycle for mTLS integrations to improve reliability and prevent service disruptions. Public certificates are:
- Reissued 60 days before expiration.
- Revoked 30 days before expiration.
These intervals will continue to shorten in line with evolving CA/B Forum guidelines which aim to reduce certificate lifetimes to a maximum of 47 days.
If you previously used links on this page to download certificates, update your process to retrieve them exclusively through the API.
Updating the mTLS certificate authority hierarchy certificate-hierarchy-update
Adobe is updating the certificate authority (CA) hierarchy used to issue client certificates for outbound mTLS connections. Industry standards require separate CA hierarchies for server and client authentication. To meet these requirements, Adobe is moving from a hierarchy that supports both server and client authentication to one dedicated to client authentication.
The following table compares the current and new certificate hierarchies.
Update your trust store as soon as possible rather than waiting for a specific connection to be affected. A trust store can hold both hierarchies at the same time, so adding the new root and intermediate does not disrupt your current connections. For certificate downloads, platform-specific instructions, verification steps, and migration details, see the mTLS certificate hierarchy migration guide.
Data at rest at-rest
Data that is ingested and used by Experience Platform is stored in the data lake, a highly granular data store containing all data managed by the system, regardless of origin or file format. All data persisted in the data lake is encrypted, stored, and managed in an isolated Microsoft Azure Data Lake Storage instance that is unique to your organization.
For details on how data at rest is encrypted in Azure Data Lake Storage, see the official Azure documentation.
Next steps
This document provided a high-level overview of how data is encrypted in Experience Platform. For more information on security procedures in Experience Platform, see the overview on governance, privacy, and security on Experience League, or take a look at the Experience Platform security whitepaper.