Edge Delivery Services sites are public by default exactly what you want for a marketing site, and exactly what you don’t want for a pre-launch staging site, a partner portal, or an intranet. Adobe documents several ways to restrict access. They differ in maturity (one is Beta), in granularity (the whole site, not individual pages), and in what they can’t do (authentication, not authorization). This post lays out the options as the docs describe them, with status labels.
The Options at a Glance
| Option | What it does | Status per Adobe’s docs |
| Site Authentication (token-based) | Only requests presenting a configured site token can reach the protected preview (*.aem.page), publish (*.aem.live), or both. | Documented capability. Not new this cycle; we did not verify when it launched. |
| CDN Basic Authentication (Adobe Managed CDN) | A username/password challenge enforced at the CDN for your custom domain. | GA. Docs say it is “not recommended for live production domains” intended for simple cases and lower environments. |
| CDN OIDC Authentication (Azure Entra ID, Okta, Google, others) | Sign-in with a third-party identity provider at the CDN, for the whole site or selected paths. | BETA. Access is by request. Not production-ready by Adobe’s own label. |
A note on naming: the AEM 2026.9.0 release notes list an “Edge Authentication (Beta)” item described as OIDC-based access restriction for Edge Delivery Services, under Early Access. The aem.live CDN documentation describes “CDN OIDC Authentication” as being in beta. These appear to be the same capability, but Adobe uses different names and labels in different places confirm with Adobe for your program. Wherever this post says OIDC, read it as Beta.
Access Control Layers Diagram
Option 1: Site Authentication (Token-Based)
Once enabled, requests to the protected tier must present a valid site token; requests without one get an HTTP 401. You can protect preview only, publish only, or both.
How Adobe documents the setup
- Enable the Configuration Service and authenticate to it.
- Create a site token by POSTing to the /secrets.json endpoint, which returns an id and a value.
- Enable token access by POSTing to /access/site.json (both tiers), /access/preview.json (aem.page only), or /access/live.json (aem.live only) with the secret’s id.
- Verify that requests without authentication now return 401.
Verify the restriction: request the preview URL with no credentials (using a browser or any command-line HTTP client). The response status should now be 401. Authenticated requests pass the site token in the Authorization header, using the exact header format given in Adobe’s documentation.
We deliberately don’t reproduce the full Admin API URLs or request bodies copy those from the current aem.live authentication docs (aem.live/docs/authentication-setup-site).
Two tokens, easy to confuse
- Auth token – obtained when you log in as an admin, used for Configuration Service requests. Highly sensitive; it cannot authenticate site visitors.
- Site token – generated through the API, shareable with users and systems, passed in the Authorization header to reach the protected site.
The documentation page we read does not describe how tokens are revoked. Check how rotation and revocation are handled before you depend on it.
The limitations, as Adobe states them
- Authentication only: “Only authentication is supported. Authorization is not supported.”
- Whole site only: “Authentication can only be enabled or disabled for the entire site.”
- No custom denial page: “It is not possible to create a custom error page for denied access.”
- Publish-tier side effect: enabling authentication on .aem.live enforces it for all visitors, and per the docs “will also prevent automatic PSI (Page Speed Insights) checks from running on your pull requests.”
- CDN guidance: every visitor request must carry the correct Authorization header, so your CDN must pass it to the origin. “Never use a custom CDN as backend for your production CDN. Always point it to the live environment directly.”
Option 2: CDN Authentication (Basic GA, OIDC Beta)
Site tokens protect the origin, but they’re a machine credential, not a login experience. For real sign-in, Adobe documents CDN-level authentication on the Adobe Managed CDN, in three parts:
- Lock access to your custom domain with an Authentication CDN rule.
- Protect the origin domain with Site Authentication (Option 1), so the origin can’t be reached around the CDN.
- Deploy the rule through a cdn.yaml file using an Edge Delivery Configuration Pipeline in Cloud Manager.
You can protect the entire site or selected paths using conditional rules on domains and URL patterns. Credentials such as client secrets belong in Pipeline Secret Variables, referenced from cdn.yaml with ${{VARIABLE_NAME}} notation not hard-coded. For the current schema, use Adobe’s Adobe Managed CDN configuration page; we haven’t reproduced one because the OIDC portion is still Beta and the schema can change.
Basic vs OIDC, plainly: Basic Authentication is GA, but Adobe itself says it’s not for live production domains. OIDC is aimed at real sign-in with your identity provider and it is Beta. If you need to protect a production site with SSO today, take that decision to Adobe rather than assuming the Beta is production-ready.
A Common Gotcha: Universal Editor Returns 401
Adobe has a knowledge-base article for this situation: with authentication enabled on the preview and live sites, the Universal Editor fails with a 401 Unauthorized error even after adding technical-account email domains to the authentication configuration. The article does not state the underlying cause. The documented fix:
- In AEM as a Cloud Service, go to Tools > Cloud Services > Edge Delivery Services Configuration.
- Open the Authentication tab.
- Populate the Site Authentication Token field with a token.
- Verify the Technical Account ID is correct and included.
- Save, then test the Universal Editor again.
Choosing: A Practical Decision Guide (Our Reading)
This is our interpretation of the documented behavior, not Adobe guidance. We haven’t implemented all of these combinations in a customer program.
| If you need… | Start with | Watch out for |
| Keep a pre-launch or staging site private | Site Authentication on preview (and/or live) | Whole-site only; PSI checks on PRs stop if you protect live |
| Share a protected site with a few known people or systems | Site tokens | Tokens are shared secrets; confirm your revocation story first |
| A quick password gate on a lower environment | CDN Basic Authentication (GA) | Adobe says not for live production domains |
| Real SSO sign-in (intranet, partner portal) | CDN OIDC (Beta) plus Site Authentication on the origin | Beta status, access by request; no per-page authorization from Site Authentication itself |
| Different content for different user groups | Design this explicitly not provided by Site Authentication | “Authorization is not supported” per the docs |
What We Haven’t Verified
- We read Adobe’s documentation on October 3, 2026. We have not implemented these configurations in a customer program.
- We did not verify when Site Authentication was introduced, so we label it “documented capability” rather than new or old.
- The OIDC item is Beta and may change; Adobe’s naming for it differs across pages.
- We have not tested the interaction between Site Authentication, a custom CDN, and every authoring tool.
- The docs we read did not describe token revocation or custom error pages for denied access.
Verify-First Checklist
- Decide which tier needs protection: preview (aem.page), publish (aem.live), or both
- Confirm you only need authentication not per-page or per-group authorization
- If protecting aem.live, plan for the impact on PSI checks on pull requests
- Confirm your CDN passes the Authorization header to the origin and points directly at the live environment
- Choose Basic (GA, lower environments) vs OIDC (Beta) deliberately
- Store client secrets as Pipeline Secret Variables, never in cdn.yaml directly
- Protect the origin with Site Authentication when you add CDN authentication
- If authors use the Universal Editor, set the Site Authentication Token in the Edge Delivery Services Configuration and test it
- Ask Adobe how site tokens are rotated or revoked before relying on them
Final Thoughts
Edge Delivery Services keeps access control deliberately simple: a token gate on the origin, and CDN-level authentication in front of it when you need a real login. That simplicity is the point and also the limit. If you need path-level or group-level authorization, plan for it outside of what these features provide. And if SSO is a hard requirement, remember that the OIDC route is Beta today.
Sources (Adobe documentation, read October 3, 2026)
- Configuring Site Authentication – aem.live/docs/authentication-setup-site
- Adobe Managed CDN Advanced Configuration – aem.live/developer/byo-cdn-adobe-managed-cdn-config
- AEM Universal Editor returns 401 error when authentication is enabled on preview/live sites – experienceleague.adobe.com/en/docs/experience-cloud-kcs/kbarticles/ka-27451
- Current Release Notes for AEM as a Cloud Service – experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/release-notes/release-notes/release-notes-current
