Adobe Experience Manager Security Guide: Harden Author, Publish and Forms Tiers

Adobe Experience Manager (AEM) runs public websites, so its weak points are the administrative paths, default accounts and technical credentials that sit one Dispatcher rule away from the internet. AEM comes as on-premise or Adobe Managed Services AEM 6.5, as AEM as a Cloud Service (AEMaaCS), and with AEM Forms, including the older AEM Forms on JEE stack. In October 2025 CISA added CVE-2025-54253, an AEM Forms on JEE flaw rated CVSS 10.0, to its Known Exploited Vulnerabilities (KEV) catalogue. This guide covers how authors, administrators and services authenticate, the default credentials and bundles to remove, the Dispatcher rules that keep administration private, technical account and service user governance, logging, and a hardening baseline drawn from Adobe's own checklists. It is for AEM architects, platform administrators and security engineers working on either deployment model.

Key takeaways

• Two default passwords, not one. AEM 6.5 has the admin account and a separate Apache Felix OSGi Web Console login; Adobe's checklist says to change both, with different strong passwords.
• The Dispatcher is the access control boundary. Adobe asks for allow-list /filter rules that deny by default and block administrative URLs such as the Web Console on publish.
• Replication and transport users must not be admin. Use a restricted copy of the bundled replication-receiver user so a stolen agent credential cannot administer publish.
• Cloud Service technical accounts are long lived secrets. The credential JSON holds a private key and client secret, certificates last a year by default, and the resulting access tokens are typically valid for 24 hours.
• AEM Forms on JEE needs its own patch track. APSB25-82 fixed CVE-2025-54253 and CVE-2025-54254 in AEM Forms on JEE 6.5.0-0108; Forms servers are often run by a different team from the sites stack.

How identity and access work in AEM

AEM stores users, groups and access control lists (ACLs) in its content repository (Apache Jackrabbit Oak). What differs between models is where people sign in.

For AEMaaCS, the strongest move is to federate the IMS organisation to your corporate identity provider, so author MFA, joiner and leaver processing and conditional access come from one place. Adobe notes that renaming the AEM Administrators product profile removes admin rights from its members, so treat profile names as configuration, not labels. The SAML Security Guide covers the federation side.

Site visitors are a separate matter. Publish instances serve anonymous users, and any visitor sign-in (closed user groups, forms, customer portals) should be reviewed as a customer identity system, not as an AEM author feature. Adobe's Anonymous Permission Hardening Package adds a deny rule that hides jcr:createdBy and jcr:lastModifiedBy from anonymous users, which stops author user names leaking through public content.

Admin roles and privileged access

• Change the admin password: in AEM 6.5 change it in the Granite Operations Users console straight after install, and give administrators named accounts in the administrators group so actions are attributable.
• Change the Felix console credentials: in the Apache Felix OSGi Management Console configuration, change User Name and Password. Anyone with the Web Console can install bundles, which is code execution on the instance.
• Remove developer tools from production: uninstall com.adobe.granite.crxde-support, com.adobe.granite.crx-explorer, com.adobe.granite.crxde-lite and the Sling bundle org.apache.sling.tooling.support.install. CRXDE Lite gives direct repository editing.
• Disable WebDAV: stop org.apache.sling.jcr.webdav and org.apache.sling.jcr.davex unless authors need them; no restart is needed.
• Cloud Service admins: keep the AEM Administrators profile small and named, require MFA at the IdP, and review Cloud Manager product profiles too, since Cloud Manager controls deployments and environment access.
• Host access: on 6.5, anyone with shell access to crx-quickstart can read the repository and the crypto keys. Manage those logons through the Privileged Access Management Guide process.

Integrations, API tokens and service accounts

AEM depends on several kinds of non-human identity, and each needs an owner, least privilege and a rotation plan.

• Service users: Sling deprecated loginAdministrative and related methods because they grant overly broad access; bundles that still use them must be allow-listed through LoginAdminAllowList.fragment configurations. Audit those fragments, since each one is code running with full repository rights. Principal-based mapping is preferred because it does not inherit permissions from group memberships.
• Technical account hygiene: the credential JSON contains a certificate, private key, clientId and clientSecret, and Adobe says to treat it as a secret. Customers can create up to ten technical accounts, including deleted ones, so do not create one per experiment. If a private key is compromised, add a new key, switch over, revoke the old certificates and delete the compromised one. All certificates under one private key count as active if any one is, so use separate keys where you need isolation.
• Older accounts: technical accounts created before mid-2023 may only be in the Contributors group; Adobe recommends adding a product profile, which is a good moment to set the minimum groups explicitly.

Store credential files in a secrets manager, never in the code repository. The Secrets Management Guide and the Service Account Security Guide cover inventory and rotation.

Known exploited vulnerabilities and patching

CVE-2025-54253 is listed in KEV (added 15 October 2025) as an AEM Forms on JEE flaw allowing arbitrary code execution. Adobe's bulletin APSB25-82, published 5 August 2025 and updated 16 October 2025, rates it CVSS 10.0 (incorrect authorisation) alongside CVE-2025-54254, an XML external entity flaw allowing arbitrary file system reads (CVSS 8.6). Both affect AEM Forms on JEE 6.5.23.0 and earlier on all platforms, both had public proof of concept code at publication, and both are fixed in AEM Forms on JEE 6.5.0-0108. For AEM 6.4, 6.3 and 6.2, Adobe directs users to customer care.

1. Know which AEM you run: AEMaaCS is updated by Adobe; AEM 6.5 service packs and AEM Forms on JEE patches are yours. Inventory Forms servers separately.
2. Track bulletins: follow Adobe's AEM and AEM Forms security bulletins and the KEV feed. See the CISA KEV Catalogue Guide.
3. Stage: apply the service pack or patch to a non-production author and publish pair, run regression and Dispatcher tests, and keep a repository backup or snapshot for rollback.
4. Reduce exposure meanwhile: confirm Forms on JEE administration and service endpoints are not reachable from the internet, and that Dispatcher filters block administrative paths.
5. Check after patching: review the Operations Dashboard Security Health Checks and hunt on any exposed, unpatched server before trusting it. See the Emergency Out-of-Band Patching Playbook.

Logging and detection

AEM writes Java application logs to error.log, request and response pairs to request.log and one line per request to access.log (in crx-quickstart/logs locally). AEMaaCS adds Apache web server, Dispatcher and CDN logs and supports forwarding to Azure Blob Storage, Datadog, HTTPD, Elasticsearch or OpenSearch, and Splunk (not for sandbox programs).

Metrics:

• Days from Adobe bulletin to patch on AEM 6.5 and Forms on JEE (target: inside the KEV due date for listed CVEs).
• Number of administrative paths reachable through the publish Dispatcher in a quarterly test (target: zero).
• Number of members in administrators and AEM Administrators, reviewed quarterly.
• Percentage of technical accounts with a named owner, a product profile and a certificate expiry date recorded.
• Number of LoginAdminAllowList entries (target: zero or declining).

Hardening baseline

Adobe asks that the AEM 6.5 checklist be applied from top to bottom. The order below follows it, with the Dispatcher checklist alongside.

1. Production Ready Mode: run AEM in Production Ready Mode, which applies many OSGi settings and removes sample We.Retail content. Remove Geometrixx content where present.
2. HTTPS: on both author and publish.
3. Hotfixes: install the latest Adobe security hotfixes and service packs.
4. Default passwords: change admin and the Felix console credentials to different strong values.
5. Error handling: custom error pages, especially 404 and 500, to stop information disclosure.
6. Dispatcher: latest version; allow-list /filter rules that deny by default; deny administrative URLs; block /etc/ and /libs/ on publish and allow only paths such as /etc/clientlibs/*; restrict which clients can flush the cache; run as a dedicated user with write access only to the cache folder; disable the .form selector.
7. CSRF and clickjacking: CSRF Protection Framework on; Apache Sling Referrer Filter with Allow Hosts set and Allow Empty unchecked; allow /libs/granite/csrf/token.json and the CSRF-Token client header at the Dispatcher; X-FRAME-OPTIONS: SAMEORIGIN.
8. Debug off: disable Debug and Timing in the Granite HTML Library Manager, disable the Day CQ WCM Debug Filter, set WCM Mode to disabled on publish, and turn off Generate Debug Info in the Sling JavaScript and JSP handlers.
9. Developer bundles and WebDAV: uninstall CRXDE and Sling tooling bundles, stop WebDAV bundles.
10. Denial of service limits: restrict selectors, set json.maximumresults in the Sling GET Servlet, disable its HTML, text and XML renderers (not JSON), and disable the AssetDownloadServlet if not needed.
11. Replication users and health checks: non-admin replication and transport users, then a clean Operations Dashboard Security Health Checks result before go-live, followed by a penetration test.

Rollback: OSGi changes should be delivered as code in content packages or the Cloud Manager pipeline so a previous package can be redeployed; test Dispatcher filter changes in a staging farm, since an over-tight filter breaks page rendering before it breaks attacks.

Choosing a model: AEMaaCS moves patching and much of the infrastructure hardening to Adobe and puts the weight on IMS federation, product profiles, technical accounts and Dispatcher configuration in code. AEM 6.5 on-premise keeps full control, and full responsibility for service packs, Felix credentials, host access and Forms on JEE. Smaller teams usually gain most from AEMaaCS; organisations with strict data residency or heavy Forms on JEE use often stay on 6.5 and need a stronger patch process.

Common misconfigurations

• Felix console left on default credentials: the admin password was changed but the separate Web Console login was not.
• Block-list Dispatcher filters: trying to deny known bad paths instead of allowing only what the site needs, leaving new selectors and servlets reachable.
• Replication agents running as admin: the agent credential becomes full admin on every publish instance.
• Technical account JSON in a repository: the private key and client secret are committed with integration code and copied into CI logs.
• Forms on JEE forgotten: the sites stack is on AEMaaCS but an old Forms on JEE server, exposed for a single workflow, is several patches behind.
• CRXDE Lite in production: developer tools left installed give anyone with author credentials direct repository write access.

Framework mapping

Practitioner checklist

• Record which AEM model, version and Forms components you run, including any Forms on JEE servers.
• Apply APSB25-82 (AEM Forms on JEE 6.5.0-0108) and current service packs; track Adobe bulletins and KEV.
• Change the admin and Felix console credentials; give administrators named accounts.
• Federate AEMaaCS IMS to your identity provider with MFA, and keep AEM Administrators and Cloud Manager profiles small.
• Set replication and transport users to restricted, non-admin accounts.
• Review Sling service user mappings and remove LoginAdminAllowList entries.
• Inventory technical accounts, store their JSON in a secrets manager and diary certificate renewal.
• Use allow-list Dispatcher filters and test that administrative URLs are blocked on publish.
• Run Production Ready Mode, remove developer bundles and WebDAV, and turn debug off.
• Forward AEM, Dispatcher and CDN logs to the SIEM and alert on console access and admin changes.

Standards and references

• Adobe: AEM 6.5 Security Checklist
• Adobe: Dispatcher Security Checklist
• Adobe: Security Bulletin APSB25-82 for AEM Forms on JEE
• Adobe: IMS Support for AEM as a Cloud Service
• Adobe: Generating Access Tokens for Server-Side APIs
• Adobe: Logging for AEM as a Cloud Service
• Apache Sling: Service Authentication
• CISA: Known Exploited Vulnerabilities Catalog

Related NHI Mgmt Group resources: Adobe ColdFusion Hardening Guide · SAML Security Guide · Secrets Management Guide · Web Application Firewall Guide · Service Account Security Guide