DocumentationExperience Cloud KCS

AEM cookie classification, behavior, and compliance validation for security and GDPR requirements

Last update: June 29, 2026

Cookies often appear on AEM-powered sites without a clear explanation of their origin, purpose, or classification, which creates GDPR and compliance risk, especially when cookies load before consent or when teams must document whether they store personal data. AEM and Adobe Experience Cloud integrations set functional and identity-related cookies as expected behavior, and these generally do not store personal data directly; consent-management platforms can misclassify them by default, and some cookies originate from infrastructure or third parties.

To resolve this, identify each cookie and its source, determine whether it stores personal data, classify it correctly for consent tools, and apply the supported security attributes.

Description description

Environment

  • Adobe Experience Manager as a Cloud Service
  • Adobe Experience Manager Managed Services
  • Adobe Experience Manager 6.5 (ContextHub)

Issue/Symptoms

  • Cookies appear on the site without a clear origin, purpose, or classification.
  • Specific cookies (such as AMCV_, AMCVS_, affinity, demdex, AWSALB) require confirmation of whether they store personal data.
  • Cookies appear before user consent in consent-management platforms.
  • Unknown cookies (such as dextp) appear after migrating to Adobe Cloud.
  • Compliance or legal teams require documentation on whether cookies store IP addresses or personal data.

Root cause

AEM and Adobe Experience Cloud integrations set functional and identity-related cookies as part of expected behavior, and these generally do not store personal data directly. When customers enable additional Adobe services such as Analytics, Audience Manager, or Target, associated cookies (for example, demdex, AMCV, mbox, at_check) appear. Infrastructure-level services such as AWS Application Load Balancer set their own cookies. Consent-management platforms may classify cookies incorrectly by default, causing them to load before consent, and some cookies (such as RT) originate from third parties.

Steps to reproduce

  • Inspect cookies in the browser developer tools under Application/Storage > Cookies, and review each cookie’s domain, path, and name.
  • Compare each cookie against its known Adobe, infrastructure, or third-party origin.
  • Inspect cookie values to confirm that none contain readable personal data.

Resolution resolution

To fix the issue:

  1. Identify the cookie and its source. Open the browser developer tools, go to Application/Storage > Cookies, review the domain, path, and name, and map each cookie to its origin:

    • AMCV_, AMCVS_, TEST_AMCV_COOKIE_WRITE - Adobe Experience Cloud ID Service
    • demdex, dextp - Adobe Audience Manager
    • AWSALB, AWSALBCORS - AWS Application Load Balancer
    • mbox, at_check, mboxEdgeCluster - Adobe Target
    • affinity - AEM load balancer routing cookie
    • RT - third-party Real User Monitoring cookie

  2. Determine whether the cookie stores personal or sensitive data:

    • AMCV/AMCVS store the ECID (an anonymous visitor ID) and do not contain PII.
    • demdex, dextp provide visitor ID sync and do not store PII.
    • AWSALB cookies do not store PII.
    • mbox/at_check store activity and session information but not PII.
    • affinity does not store PII.
    • RT is not set by Adobe and is usually a third-party performance cookie.

  3. Classify the cookie for GDPR and consent tools, then confirm the classifications with your legal or privacy team:

    • Strictly necessary / technical: affinity, AWSALB, TEST_AMCV_COOKIE_WRITE, and many ECID cookies when required for core functionality.
    • Performance / targeting: AMCV, AMCVS, demdex, mbox when used for analytics, personalization, or audience building.
    • Third-party: RT.

  4. Ensure cookies do not load before consent when required. In your consent tool, categorize cookies into the groups defined in the previous step. Then clear browser storage, reload the page, and confirm that consent-required cookies (such as demdex and AMCV) are absent until consent is given. Confirm that Adobe libraries (Analytics, Target, Launch) are blocked by the consent script until approval.

  5. Configure Secure or HttpOnly flags when required by compliance (Managed Services only, not AEM as a Cloud Service). In the AEM Web Console, go to /system/console/configMgr, open the org.apache.felix.http configuration, and enable the Secure flag for standard HTTP cookies. Ensure the site is served exclusively over HTTPS, which is required for the Secure flag. Note that HttpOnly cannot be applied to AMCV/AMCVS cookies because JavaScript access is required.

  6. Validate client-side storage for ContextHub (AEM 6.5 Managed Services only). Confirm that data is stored in browser localStorage or sessionStorage unless explicitly configured otherwise, using Application > Local Storage in the developer tools.

  7. Validate the result. Clear browser storage and reload to confirm that cookies load only under the correct regulatory category, inspect cookie values to confirm none contain personal data, and verify that Secure flags apply correctly on HTTPS pages where configured (Managed Services only).

  8. If a cookie cannot be identified, appears to store readable personal information, or still loads before consent after classification, contact Adobe Support with a screenshot of the cookie values, the environment type (AEMaaCS or Managed Services), the list of enabled Adobe solutions (Analytics, Target, Audience Manager), and your consent tool configuration.

recommendation-more-help
experience-cloud-kcs-help-kbarticles