AEM Dynamic Media: The Complete Guide

Dynamic Media replaces the archaic, compute-heavy world of generating 47 static renditions per image, yet most teams waste months debugging opaque sync failures they could have easily prevented. The old paradigm of processing cq5dam.web.1280.1280.jpeg on the AEM Author instance is dead. By enabling Dynamic Media, you offload the massive burden of image manipulation, video encoding, and intelligent cropping directly to Adobe's globally distributed delivery network (formerly known as Scene7). However, integrating this external powerhouse back into your AEM workflow introduces a complex synchronization architecture that demands rigorous understanding.

This comprehensive guide systematically tears down Dynamic Media from the ground up, starting with the core architecture and transitioning into advanced delivery techniques. We will meticulously cover:

• The fundamental Scene7 synchronization architecture and Hybrid vs. Scene7 mode differences.
• A complete URL modifier reference for dynamic on-the-fly image manipulation, including layer text, watermarks, and positioning.
• Deep dives into Smart Crop configurations powered by Adobe Sensei, and how AI bounds are stored in AEM.
• Advanced Video Profiles, encoding presets, and adaptive bitrate streaming (HLS/DASH).
• Rich Media Sets: Image Sets, Spin Sets, Mixed Media Sets, and eCatalogs.
• The cutting-edge Dynamic Media with OpenAPI for next-gen delivery.
• The critical JCR properties driving the integration (dam:scene7File, dam:scene7SyncStatus, etc.).
• A comprehensive troubleshooting framework and 404 resolution flowchart for both authors and frontend developers.
• Performance optimizations including CDN caching headers, format negotiation (WebP/AVIF), and Core Web Vitals (CWV) improvements.
• A definitive comparison between Dynamic Media, Standard Web Renditions, and Named Image Transforms.

Before diving into the complex synchronization topologies of Dynamic Media, ensure you have a firm grasp on the underlying systems. I highly recommend reviewing the AEM Architecture Complete Guide and the AEM Assets (DAM) Complete Guide. Because Dynamic Media intrinsically ties into your site's presentation layer and delivery performance, keep the AEM Frontend Integration Complete Guide, the AEM Performance Troubleshooting Complete Guide, and the AEM Core Components Style System Complete Guide open as essential references.

The Scene7 sync architecture

When you upload an image to AEM Assets without Dynamic Media, the AEM Asset Update Workflow (or microservices in AEM as a Cloud Service) creates predefined static renditions and stores them directly in the Java Content Repository (JCR) beneath the asset's /jcr:content/renditions node. This process is inherently monolithic. If your marketing team decides they need a new 16:9 banner rendition, you must reprocess every asset in the DAM.

Dynamic Media fundamentally shifts this paradigm by operating as a synchronized, decoupled rendering engine. It functions as a complete headless media delivery infrastructure seamlessly grafted onto the AEM authoring experience.

How Synchronization Actually Works

When Dynamic Media is enabled, AEM acts as the central orchestration hub, but the actual image processing and delivery are handed off to the Scene7 Publishing System (SPS). The architecture follows these precise steps:

1. Asset Ingestion: A user uploads a high-resolution master asset (e.g., a 100MB TIFF) to the AEM DAM. The initial upload goes directly into the AEM JCR blob store or external data store.
2. Metadata Extraction & PTIFF Generation: In AEM as a Cloud Service, Asset Compute Microservices extract the metadata. Crucially, a Pyramid TIFF (PTIFF) is generated. This PTIFF is a specially encoded, multi-resolution image file that allows the Scene7 engine to rapidly extract only the necessary pixels for any requested size without loading the entire 100MB file into memory. For legacy 6.5, this is handled by the heavy com.day.cq.dam.scene7 bundle.
3. Synchronization Trigger: AEM detects the new or modified asset and triggers the Scene7 synchronization process via an authenticated API call. AEM pushes the PTIFF and necessary metadata to the Scene7 infrastructure over secure channels.
4. Scene7 Processing: The Scene7 engine ingests the asset, checks for uniqueness, generates a unique identifier (dam:scene7File), and prepares it for distribution across the Scene7 CDN edge nodes.
5. Status Callback: Scene7 sends a callback to AEM confirming successful ingestion, updating the JCR metadata properties on the asset to indicate it is ready for dynamic delivery. This polling/callback mechanism is historically where 90% of DM bugs originate.
6. Dynamic Delivery: When a user visits your website, the HTML generated by AEM components (like the Core Image Component) outputs a Dynamic Media URL instead of a local AEM path. The user's browser requests the image directly from the Scene7 CDN, passing parameters (modifiers) that dictate exactly how the image should be rendered on the fly.

Scene7 vs. Hybrid Mode

Understanding the difference between the legacy deployment modes is crucial, even though AEM as a Cloud Service standardizes on the modernized architecture. These modes govern exactly where the synchronization data flows.

• Hybrid Mode: The classic AEM 6.5 deployment. AEM Authors synchronize with Scene7. However, the AEM Publish tier handles delivery of the AEM pages while the Scene7 CDN handles the media. The complexity here lies in the fact that AEM Publish must also have an active connection to Scene7 to dynamically fetch viewers and ensure URLs are correctly formatted. If the Publish tier loses connection to the Scene7 API, media fails to render even if the AEM Author successfully synced the file.
• AEM as a Cloud Service (AEMaaCS) Mode: In the cloud native environment, Dynamic Media is deeply integrated. Asset Compute Microservices directly interface with the Scene7 backend. The reliance on legacy workflows is eliminated, replacing them with a highly scalable serverless architecture that drastically reduces synchronization latency. Publish nodes do not need back-channel communication to Scene7; everything is resolved securely via edge workers.

The JCR Property Reference

The bridge between AEM's JCR and the Scene7 backend is maintained entirely through metadata properties stored on the asset's /jcr:content/metadata node. If synchronization fails, these properties are the first place you look. Every AEM developer must memorize these node structures.

When a developer complains that an image is rendering as a local AEM path (e.g., /content/dam/project/hero.jpg) instead of a DM URL, the very first step is to check if dam:scene7File is populated. If it's missing, the synchronization has failed. The Core Image component's Sling Model explicitly checks for this property; if absent, it falls back to the local cq5dam.web renditions.

Image Presets and the URL modifier API

The true power of Dynamic Media lies in the Image Serving API, colloquially known as URL Modifiers. Instead of generating a specific 800x600 image and saving it to disk, Dynamic Media renders the image exactly when the browser requests it by appending query string parameters to the URL. This enables true responsive design where art direction is manipulated instantly at the edge.

A standard Dynamic Media URL looks like this: https://s7d1.scene7.com/is/image/AdobeEnterprise/hero-banner?wid=1200&fmt=webp&qlt=85&fit=constrain

Complete URL Modifier Reference Table

Mastering these modifiers allows you to solve almost any complex responsive design requirement without ever touching AEM backend code. The Scene7 API supports hundreds of commands, but these are the critical ones for modern development.

Image Presets: Reusable Configurations

Instead of developers hardcoding ?wid=1200&fmt=webp&qlt=85&op_sharpen=1 everywhere in their frontend code, AEM allows you to create Image Presets.

An Image Preset is a named collection of these modifiers managed within the AEM authoring interface (Tools > Assets > Image Presets). If you create a preset named Hero_Desktop_HighRes, the URL simplifies to: https://s7d1.scene7.com/is/image/AdobeEnterprise/hero-banner?$Hero_Desktop_HighRes$

Notice the $ signs surrounding the preset name.

Best Practice: Always use Image Presets instead of hardcoded modifiers in your HTL or React components. If the marketing team decides to change the global image quality from 85 to 80 to save bandwidth, updating the Image Preset applies the change globally and instantly across the entire site without a code deployment. Furthermore, Image Presets are heavily cached at the Scene7 CDN tier, improving cache hit ratios compared to infinitely variable ad-hoc parameters.

Smart Crop and Image Profiles

Historically, solving the "art direction" problem in responsive design required a designer to manually open Photoshop and crop an image multiple times (Desktop, Tablet, Mobile) to ensure the focal point (e.g., a model's face) wasn't cut off when the aspect ratio changed from 16:9 to 1:1.

Smart Crop, powered by Adobe Sensei (Adobe's AI/ML framework), automates this entirely.

How Smart Crop Works

1. Define Image Profiles: In AEM (Tools > Assets > Image Profiles), you create a profile that defines your required aspect ratios and dimensions (e.g., Mobile: 600x600, Tablet: 800x600, Desktop: 1200x400).
2. Apply to Folders: You apply this Image Profile to specific folders in the DAM via the folder properties interface. This cascades down to subfolders.
3. AI Processing: When an image is uploaded to that folder, AEM sends it to Scene7. Adobe Sensei analyzes the image to identify the most salient features (faces, text, high-contrast objects). It utilizes advanced machine learning models trained on millions of images to understand human-centric focal points.
4. Automatic Cropping: Sensei automatically generates the bounding boxes for the requested aspect ratios, ensuring the focal point remains centered.
5. Review and Override: Authors can preview the generated Smart Crops in the AEM Asset Details view. If Sensei makes a mistake (e.g., cropping out a vital product logo in the corner), the author can manually adjust the bounding box. These overrides are written back to Scene7 instantly.
6. Delivery via URL: The frontend retrieves the specific crop using a specific modifier format appended to the base Scene7 URL.

The Smart Crop Delivery Mechanism

When you request a Smart Crop, the URL looks different from a standard Image Preset.

Standard Image Preset: .../is/image/Company/image?$Mobile$ Smart Crop Request: .../is/image/Company/image:Mobile

Notice the colon : instead of the ?$Preset$. This syntax tells the Scene7 rendering engine, "Do not just apply a blind center-crop. Look up the specific Smart Crop coordinates generated by Adobe Sensei for the profile named 'Mobile' and apply that exact region."

Under the hood, the engine translates the :Mobile request into the complex rgn=x,y,w,h modifier coordinates stored in the Scene7 database. If you inspect the raw Scene7 API response for a Smart Cropped image, you will see it outputting normalized fractional coordinates to ensure the crop scales perfectly regardless of the base image resolution.

Advanced Video Profiles: HLS and DASH

Dynamic Media is not just for images; it is an enterprise-grade video encoding and delivery platform. Just as uploading a static MP4 to an AEM page is a terrible idea for global performance, relying on AEM to deliver large video payloads will quickly saturate your publish dispatcher bandwidth and lead to terrible user experiences.

The Problem with Progressive Download

Historically, videos were delivered via progressive download (e.g., <video src="/content/dam/video.mp4">). The browser downloads a single large MP4 file. If the user is on a slow 3G mobile connection, the 1080p video buffers endlessly. If they are on a 1Gbps fiber connection, it plays fine. Progressive download cannot adapt to fluctuating network conditions. It also wastes massive amounts of bandwidth if the user pauses and navigates away after watching only 5 seconds.

Adaptive Bitrate Streaming (ABR)

Dynamic Media solves this using Adaptive Bitrate Streaming via HLS (HTTP Live Streaming, pushed by Apple) and DASH (Dynamic Adaptive Streaming over HTTP, the international standard).

When you upload a master video (e.g., a 4K ProRes .mov file) to a folder governed by a Video Profile:

1. Dynamic Media ingests the heavy master file.
2. The encoding engine (powered by highly optimized cloud transcoders akin to FFmpeg) transcodes the video into multiple different bitrates and resolutions simultaneously. For example:
   • 1080p at 5Mbps (High Quality)
   • 720p at 2.5Mbps (Medium Quality)
   • 480p at 1Mbps (Low Quality)
   • 360p at 400Kbps (Fallback Quality)
3. It segments each of these streams into tiny chunks (usually 2 to 10 seconds long).
4. It generates an .m3u8 (HLS) and .mpd (DASH) manifest file. This manifest tells the video player exactly where all the chunks are located and their respective bitrates.

The DM Viewer SDK and Video Delivery

To play adaptive video, you cannot simply use a standard HTML5 <video> tag pointing to an .m3u8 file (unless you are exclusively on Safari, which has native HLS support). You need a specialized video player capable of reading the manifest, measuring the user's current bandwidth, and seamlessly switching between the 1080p and 480p streams mid-playback without stuttering.

This is where the Dynamic Media Viewer SDK (often integrated via the AEM Core Components) comes in. The viewer JavaScript evaluates the user's connection, starts by loading the lowest bitrate chunk to ensure immediate playback (zero buffering), and then rapidly scales up to the highest quality stream the connection can support.

A standard Adaptive Video request looks like this: https://s7d1.scene7.com/s7viewers/html5/VideoViewer.html?asset=AdobeEnterprise/hero-video

You can customize the player chrome, controls, analytics tracking, and closed captioning directly within the DM Viewer preset configuration in AEM.

Rich Media Sets: Spin Sets, Mixed Media Sets, eCatalogs

For eCommerce and highly interactive product experiences, Dynamic Media offers specialized asset aggregation capabilities.

• Image Sets: Groups multiple images of a single product (front, back, side) into a unified viewer. A single call to the DM Viewer SDK loads the entire set, providing an interactive gallery experience without custom frontend carousel development.
• Spin Sets: Allows users to interactively rotate a product in 3D. Authors upload a series of precisely timed photographs (e.g., 36 frames of a shoe rotating on a turntable). Scene7 generates a composite viewer that allows smooth drag-to-rotate functionality.
• Mixed Media Sets: Combines Image Sets, Spin Sets, and Videos into a single interactive viewer container.
• eCatalogs: Converts multipage PDFs into interactive, flippable digital magazines. Users can search text, zoom infinitely into vector data, and click defined hotspots to open product modal windows.

These rich media sets are identified in the JCR by specific dam:scene7Type properties and are rendered using distinct viewer JavaScript bundles provided by the Scene7 CDN.

Dynamic Media with OpenAPI (Next-Gen Delivery)

For years, AEM developers have complained about the complexity of the Scene7 delivery domain structure, the esoteric URL parameters, and the heavy dependency on the legacy DM Viewer SDK (which injects substantial JavaScript overhead).

To address this, Adobe introduced Dynamic Media with OpenAPI (often referred to as Next-Gen Dynamic Media or Asset Delivery).

This is a massive architectural shift. Instead of syncing assets to a separate Scene7 storage bucket and using the legacy s7d1.scene7.com domain, Next-Gen Delivery leverages a unified edge architecture natively bound to AEM as a Cloud Service.

Key Innovations in OpenAPI Delivery

1. Unified Edge Domain: Assets are delivered from the same domain as your website, or a deeply integrated edge domain, eliminating the CORS complexities and third-party DNS lookups associated with scene7.com.
2. Simplified URL Structure: The API embraces modern RESTful paradigms. Instead of the archaic Scene7 modifiers, the URLs are semantic and predictable. Legacy: /is/image/Company/asset?wid=500&fmt=webp Next-Gen: /adobe/assets/urn:aaid:aem:uuid/renditions/original?width=500&format=webp
3. URN-Based Addressing: Assets are addressed by their immutable Universal Resource Name (URN), ensuring links never break even if the file is moved, renamed, or restructured in the DAM.
4. Native SEO: Because the assets can be served directly from your primary canonical domain (e.g., www.yourcompany.com/adobe/assets/...), search engines treat them as first-party content, drastically improving image SEO rankings and simplifying sitemap generation.
5. Microservice Architecture: By avoiding the legacy Scene7 sync bottleneck, Next-Gen delivery provides near-instantaneous availability of media assets directly from the Cloud Service edge nodes.

While legacy Scene7 remains fully supported and deeply embedded in thousands of enterprise sites, any new AEM as a Cloud Service implementation should evaluate Dynamic Media with OpenAPI as the primary delivery mechanism, especially for headless architectures, SPA (Single Page Applications), and modern React/Next.js frontends.

A complete troubleshooting flowchart for 'image uploaded but DM URL returns 404'

The most common ticket an AEM developer receives regarding Dynamic Media is: "I uploaded an image, I added it to the page, but the image is broken and returning a 404 from Scene7."

Do not randomly restart bundles or guess. Follow this precise debugging flowchart.

[User reports broken DM Image (404)]
         |
         v
[Inspect DOM to get the failing URL]
         |
         v
Are they using the correct DM Domain? (e.g., s7d1.scene7.com)
  ├── NO  --> Fix the OSGi Configuration (Day CQ Scene7 API / Cloud Services).
  └── YES --> Copy the 'dam:scene7File' value from the URL (e.g., Company/image-1).
         |
         v
[Open CRXDE Lite or AEM Assets interface for the specific asset]
         |
         v
Does the asset have a 'dam:scene7ID' and 'dam:scene7File' property?
  ├── NO  --> SYNC FAILURE. 
  |           Check the 'dam:scene7SyncStatus' property.
  |           If 'Failed', check 'dam:scene7APIResponse' for the raw error.
  |           Fix: Re-upload or re-process the asset via AEM workflow.
  |           Root Cause Check: Ensure the asset format is supported by DM (e.g., not a .doc file).
  └── YES --> SYNC SUCCESSFUL (from AEM's perspective).
         |
         v
Does the 'dam:scene7File' property match the value requested in the failing URL?
  ├── NO  --> STALE CACHE. 
  |           The component HTL is rendering an old ID, or Dispatcher/CDN is caching the old HTML.
  |           Fix: Invalidate Dispatcher cache for the page.
  └── YES --> Proceed to IPS Validation.
         |
         v
[Log into the native Scene7 Publishing System (SPS) Web Interface]
         |
         v
Search for the 'dam:scene7File' identifier. Does the asset exist in SPS?
  ├── NO  --> ORPHANED METADATA. 
  |           AEM thinks it synced, but Scene7 deleted it or the sync failed silently.
  |           Fix: Force re-sync the asset from AEM (select asset -> Re-process).
  └── YES --> Is the asset marked as 'Published' (Green globe icon) in SPS?
         |
         +--> NO  --> PUBLISH FAILURE. 
         |            The asset was ingested into Scene7, but not pushed to the Scene7 CDN edge servers.
         |            Fix: Trigger a Manual Publish job within the SPS interface.
         +--> YES --> DNS, WAF, or CDN OUTAGE. 
                      The asset is fully published on the Scene7 CDN. If a 404 persists, there is a firewall block, a routing issue with your specific custom CNAME (e.g., Akamai mapping), or an active CDN outage. Verify headers directly via cURL.

Performance optimization: CDN caching, format negotiation, and CWV

Dynamic Media is extremely fast, but improper configuration can ruin your site's performance and tank your Core Web Vitals (CWV), specifically Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS).

1. Enforce WebP or AVIF Next-Gen Formats

Never serve raw JPEGs or PNGs to modern browsers. You can achieve massive payload reductions (often 30-50%) by converting to WebP.

• The Bad Way: Forcing authors to upload .webp files manually. This breaks backwards compatibility with older systems and forces authors to do format conversion offline.
• The Dynamic Media Way: Authors upload standard high-res JPEGs or TIFFs. You append &fmt=webp to the Image Preset.

Even better, Dynamic Media supports Format Negotiation. If you configure the Image Preset to use fmt=webp but a user on an ancient version of Safari requests the image, the Scene7 CDN edge will detect the Accept headers from the browser. If the browser does not explicitly state it supports image/webp, the CDN will silently gracefully degrade and serve a highly optimized JPEG instead, ensuring the image always renders flawlessly.

2. Browser Caching and TTLs

The Scene7 CDN sets very aggressive edge caching headers by default (often 10 years). However, you must ensure the browser is also caching the media to prevent re-downloading on subsequent page views.

Verify the headers returning from your s7d1.scene7.com requests. You should see: Cache-Control: max-age=31536000, public, immutable

The immutable directive is critical for modern performance. It tells the browser, "This asset will never change. Even if the user clicks reload, do not bother sending an If-Modified-Since request to check if it's updated. Just serve it instantly from the local disk cache."

How can you safely use immutable? Because Dynamic Media asset URLs are generally bound to a specific iteration of the asset. If an author modifies the image in AEM, AEM will often append a cache-busting timestamp to the URL (e.g., ?ts=1698765432), guaranteeing the browser fetches the new version while safely caching the old one forever.

3. Preloading the LCP Image for Core Web Vitals

The hero banner is almost always your LCP element. Because Dynamic Media operates on a third-party domain by default, the browser must perform DNS resolution, TCP handshake, and TLS negotiation with s7d1.scene7.com before it can even begin downloading the image.

To optimize CWV and achieve a "Good" LCP score, you must eliminate this connection latency. Add a preconnect tag to your document <head>:

<link rel="preconnect" href="https://s7d1.scene7.com" crossorigin>

Furthermore, if you know exactly which Dynamic Media URL will serve the hero image, preload it immediately in the head:

<link rel="preload" as="image" href="https://s7d1.scene7.com/is/image/Company/hero-banner?wid=1920&fmt=webp" fetchpriority="high">

Using fetchpriority="high" guarantees the browser prioritizes this DM asset over background JavaScript and CSS, vastly improving your LCP score.

4. Preventing Cumulative Layout Shift (CLS)

Because Dynamic Media images load asynchronously from an external domain, they can cause massive layout shifts (CLS) if you do not explicitly define the aspect ratio in your CSS or HTML. The browser doesn't know how tall the image will be until it parses the metadata, causing the page to jump.

Always include width and height attributes on your <img> tags, or utilize the CSS aspect-ratio property on the image container. AEM Core Components handle this automatically if configured correctly.

Comparison table: Dynamic Media vs standard web renditions vs Named Image Transform

A common architectural debate is knowing exactly when to use which image processing engine. Do not over-engineer; pick the right tool for the job. Here is the definitive decision matrix.

The Verdict: If your organization pays for the Dynamic Media license, you should be using it for 100% of your frontend website imagery. Relying on AEM Core Component Named Image Transforms (e.g., .coreimg.jpeg) when you have Dynamic Media active is an architectural failure that wastes Publish tier CPU and fills your Dispatcher cache with redundant media files.

Cheat Sheet

• Base URL Structure: https://[domain]/is/image/[company]/[asset-name]?[modifiers]
• The essential modifiers: wid, fmt, qlt, fit, op_sharpen.
• Image Preset invocation: ?$PresetName$
• Smart Crop invocation: :ProfileName
• Format Negotiation: Use fmt=webp to fallback to JPEG automatically if unsupported.
• JCR Source of Truth: /jcr:content/metadata/dam:scene7File
• AEM Configuration Path: /conf/global/settings/cloudconfigs/dmscene7

Best Practices

• Always use WebP/AVIF: Hardcode fmt=webp in your Image Presets. It reduces payload sizes significantly.
• Always apply op_sharpen=1: Downscaling images naturally blurs them. A light unsharp mask is required to maintain professional crispness.
• Leverage AEM Core Components: The out-of-the-box Image (v3) component has native, deeply integrated support for Dynamic Media and Smart Crop. Do not reinvent the wheel by writing a custom React wrapper around raw Scene7 URLs unless you are building a fully headless application.
• Configure a Custom CNAME: Instead of serving assets from s7d1.scene7.com, configure a vanity domain like media.yourcompany.com. It builds brand trust, avoids ad-blocker false positives, and simplifies cross-origin resource sharing (CORS).
• Implement Cache Invalidation: Set up automated cache invalidation logic between AEM and the Scene7 CDN if you frequently update assets without changing their filenames.

Do's and Don'ts

• DO use Smart Crop to automate art direction across mobile and desktop viewports, saving hundreds of hours of design work.
• DO ensure your authors upload the absolute highest resolution master files available. Scene7 needs the raw pixel data to generate high-quality renditions.
• DO monitor the dam:scene7SyncStatus property via AEM Reports to proactively catch failed syncs before the business notices broken images.
• DON'T use Dynamic Media to deliver standard CSS background sprites or tiny UI icons (like a 16x16 magnifying glass). Keep those bundled in your frontend codebase or SVG sprite sheets to avoid unnecessary external HTTP requests.
• DON'T chain dozens of manual modifiers together in your code. (e.g., ?wid=100&hei=100&crop=10,10,50,50&op_blur=5). Abstract these complex requirements into a named Image Preset managed by authors.
• DON'T upload PDFs and expect Dynamic Media to magically turn them into interactive flipbooks without configuring an eCatalog viewer. DM treats PDFs as rasterizable documents first.

Mastering Dynamic Media elevates an AEM engineer from someone who just writes HTL components to an architect capable of delivering lightning-fast, visually stunning experiences at a global scale. Stop relying on the AEM JVM to process images, embrace the power of the edge, and optimize those URL modifiers.

Security and Access Control

When integrating Dynamic Media, many teams overlook the security implications. Scene7 delivery is fundamentally public. If an asset is synchronized to Scene7 and published to the edge, anyone with the generated URL can view it, regardless of the AEM Closed User Group (CUG) permissions applied to the original asset in the DAM.

The CUG Limitation

If you have a secure portal built on AEM and you apply a CUG to the /content/dam/secure-assets folder, AEM Publish will correctly block unauthenticated users from downloading the master file. However, if that folder is synchronized to Dynamic Media, the s7d1.scene7.com URL will bypass AEM entirely and serve the media.

To mitigate this:

1. Do not sync secure assets: Configure your AEM Cloud Services to explicitly exclude secure folders from Scene7 synchronization.
2. Use AEM Publish for secure delivery: For sensitive internal documents or premium paywalled content, rely on standard AEM delivery where access control checks can intercept the request.
3. Tokenized Delivery (Advanced): Scene7 offers advanced tokenized delivery where URLs require a dynamically generated cryptographic signature to render, but this requires substantial custom development.

Keep the AEM Security, Users, Groups and ACLs Complete Guide handy when designing your DAM taxonomy to prevent accidental public disclosure of confidential media.