Restricting Asset Delivery in AEM Dynamic Media with OpenAPI: What the Docs Say, and What to Test Before You Rely on It

Question

If your DAM serves brand assets to other apps through delivery URLs, “approved” and “public” aren’t the same thing. Dynamic Media with OpenAPI capabilities now offers ways to limit who can fetch an asset. Here’s what Adobe’s documentation says, with the status and caveats marked.

1. What it is (existing capability, not a 2026 launch)

Dynamic Media with OpenAPI is a set of search and delivery APIs on AEM Assets as a Cloud Service. Each approved asset gets a delivery URL, and consuming apps reference that URL rather than copying binaries. Adobe says changes to approved assets appear in delivery URLs within a 10-minute CDN TTL. It supports on-the-fly image modifiers (width, height, crop, format, smart crop and others), WebP, and HLS/DASH video. DM Prime customers get only the basic image modifiers.

2. Two ways to restrict delivery

a) By time window (documented how-to). Set an On Time and/or Off Time under “Scheduled (de) activation” in asset properties. Before On Time, the asset stays inactive. At Off Time, its delivery URL stops serving it. If the fields are missing, add Date fields labeled “On Time” / “Off Time” mapped to ./jcr:content/onTime and ./jcr:content/offTime in your metadata schema.

b) By IMS user or group. DAM Admins or Brand Managers can limit delivery of an approved asset, down to a single asset, to selected Adobe IMS users or groups. Only authorized IMS-onboarded users get it through the Search and Delivery APIs. This isn’t self-service: the docs say to contact Enterprise Support to configure access on the author service. The release notes list “Secure Delivery with Attribute-based Access Control” as a Limited Availability feature in 2026.9.0, while the how-to page itself states no status label. I couldn’t find a documented metadata field name for the user/group rules, so I can’t describe the exact rule syntax.

3. What unauthorized callers get: a 404

Per the docs, a request with no token, or a token that doesn’t belong to an authorized user or group, returns 404, and a valid authorized Bearer token returns 200 with the binary. That’s good for not leaking existence, but it makes debugging harder: a 404 might mean a wrong URL, an unapproved asset, an expired time window or a missing permission. Build that into your support runbooks.

4. Token handling: don’t ship the developer token

For integrations outside Asset Selector, you need an IMS Bearer token from a server-to-server integration. Adobe provides a short-lived developer-flow token for limited local testing only, and says not to use it in production. Never expose a long-lived credential in front-end code to fetch restricted assets.

5. A custom identity provider needs extra setup

For a custom IdP, the docs describe secure cookie delivery that requires a custom delivery domain that is a subdomain of the publish domain, a delivery-token cookie set on the publish domain after authentication, and an Enterprise Support ticket. Treat this as a project with lead time, not a configuration toggle.

6. Gotchas worth testing

Enablement: the feature has to be enabled via an Adobe Support ticket (program/environment ID, use case, downstream apps). Non-Adobe apps need their hosting domains allow-listed.
Content packages: exclude /conf/global/settings/dam/assets-configurations/assetdelivery from your packages, because including it can deactivate the feature.
Licensing: the docs require AEM Assets as a Cloud Service and Dynamic Media licenses. A separate Adobe KB article says the Assets Delivery API isn’t available on a Standard license, so confirm your tier.
Propagation: Adobe states a 10-minute window for asset updates. I didn’t find a statement that this applies to access changes, so test how fast revoking access takes effect before you use it for time-sensitive content.

Bottom line

For campaign embargoes and partner-only assets, the time-window option is the simpler, documented route. IMS user/group restriction is the stronger control, but it’s Limited Availability, support-assisted and token-dependent, so pilot it before promising it to a compliance team.

Has anyone enabled user/group restricted delivery in a real program? How long it took through support, and how you handled non-IMS consumers, would help others.