Autonomous Digital Experience Management (ADEM) measures the experience users and sites have when accessing applications through or alongside Prisma Access. It adds an important perspective to security operations: tunnels, policies, and gateways can all be healthy while users still experience poor DNS, Wi-Fi, ISP, SASE path, SaaS, or private-application performance.
Within Palo Alto Security Operations, ADEM is the service-experience layer. Current capabilities include endpoint monitoring, Browser-Based Real User Monitoring, and synthetic application tests. Monitoring spans segments from the user or remote site toward the application so operators can isolate where degradation begins.
ADEM requires the appropriate Prisma Access and ADEM/Strata Cloud Manager licensing depending on the deployment and feature.
Endpoint monitoring provides user-device context
Endpoint monitoring observes client-side and network-path signals from supported endpoints.
This helps distinguish whether poor application experience begins on the device, local Wi-Fi/LAN, ISP, Prisma Access path, or farther toward the application.
Without endpoint context, a cloud operations team may blame Prisma Access for a problem caused by one overloaded laptop or home router.
Browser-based RUM measures real user experience
Browser-Based Real User Monitoring captures the experience of actual browser sessions for supported Prisma Access Browser deployments and applications.
Real-user data is valuable because it reflects the application paths and timing users really encounter rather than one synthetic transaction.
It should be interpreted alongside privacy and data-collection policy because browser monitoring can create user-level experience telemetry.
Synthetic application tests provide continuous baselines
ADEM application tests simulate traffic to application targets even when a real user is not actively using the application.
Current documentation allows one application test to monitor multiple targets and supports web/path testing patterns.
Synthetic tests are useful for detecting degradation before the help desk receives enough complaints to establish a pattern.
Mobile users and remote sites can both be monitored
Application tests can be assigned to mobile users or mobile-user groups and can also be configured for remote sites or Prisma Access locations depending on the deployment.
This lets operations compare the same application across different user populations.
If only one branch is degraded while mobile users are healthy, the investigation should begin closer to that branch path rather than at the application service globally.
Tests should represent important user journeys
Do not create synthetic tests for every URL simply because the platform allows it.
Prioritize login endpoints, critical SaaS workflows, private applications, DNS-dependent services, and APIs that represent meaningful user work.
A test should have an owner and expected SLO so operators know what degradation requires action.
Segment-level visibility shortens fault isolation
ADEM can help identify whether degradation occurs in endpoint, Wi-Fi/LAN, ISP, Prisma Access/SASE, or application segments.
This reduces the classic network incident where each provider proves its own component is “up” while nobody can explain the slow user transaction.
Segment data should be combined with tunnel, routing, and application logs when the boundary is ambiguous.
Baseline change matters more than one raw latency number
ADEM uses observed performance to establish expected behavior and alert on degradation.
A 100 ms response may be normal for one global SaaS service and severe for an internal application that normally responds in 10 ms.
Operations should focus on change relative to user/service expectations rather than applying one threshold to every application.
Prisma Access tunnel health should be correlated with experience
Remote network and service connection dashboards can show connectivity state, while ADEM shows the application experience over the resulting path.
A tunnel can remain up as packet loss or congestion rises enough to hurt users.
Prisma Access Remote Networks and Prisma Access Service Connections provide the underlying connectivity context.
Incident triage should compare affected and unaffected cohorts
Compare geography, ISP, Prisma Access location, endpoint type, user group, branch, and application target.
If only one ISP or one remote network is affected, the blast radius is narrower. If every cohort shows the same application degradation, the application or upstream service becomes more likely.
Cohort comparison turns experience monitoring into faster hypothesis testing.
Monitoring changes should be validated after network/security changes
Changes to routing, SD-WAN, decryption, Prisma Access location, service connection, DNS, endpoint policy, or application hosting can alter the user path.
Review ADEM metrics after such changes so the team can see whether the new architecture improved or degraded experience.
Security changes are successful only when they preserve the required business service.
ADEM succeeds when user experience becomes part of security operations evidence
The mature operations model can move from a user complaint to endpoint, network segment, Prisma Access path, and application evidence without guessing which team owns the problem.
ADEM does not replace packet, routing, or application logs. It adds the user-centered signal that tells teams whether the secure architecture is actually delivering a usable service.
ADEM data should be connected to application ownership. A security operations team can identify that one SaaS service is degraded, but the service owner needs the evidence to determine whether the provider, network, authentication layer, or client behavior changed. Alerts should route to the team that can act on the failing segment.
Experience scores should be interpreted as summaries, not the full diagnosis. Operators should drill into latency, DNS, TCP/TLS, endpoint, path, and application-test details before deciding what to fix. One composite score is useful for prioritization but can hide the underlying dimension that moved.
Synthetic tests should avoid creating unintended load or side effects. Authentication, purchase, form-submission, or write-oriented journeys need test accounts and safe endpoints so monitoring does not alter production data or trigger fraud controls.
Remote-site tests should be placed where they represent real branch traffic. A synthetic test from a Prisma Access location alone may prove cloud-to-app performance while missing the branch ISP or LAN segment that users traverse. Test origin should match the question being asked.
Monitoring coverage should be tracked. ADEM may have excellent data for managed mobile endpoints but limited visibility for unmanaged users or certain branches. Dashboards should distinguish “healthy” from “not instrumented” so missing telemetry does not appear as good experience.
After an incident, save representative ADEM evidence with the incident timeline. Experience degradation before, during, and after remediation can show whether the fix restored the service and can provide provider escalation evidence when the fault was outside the enterprise boundary.
ADEM alert thresholds should match support impact. A small latency increase on a background application may be informational, while the same degradation on authentication or contact-center software may justify immediate incident response.
Experience monitoring can also validate provider changes. When an ISP, SaaS region, Prisma Access location, or private application hosting region changes, compare ADEM baselines before and after the migration rather than relying only on synthetic pre-cutover tests.
Browser RUM and endpoint monitoring can reveal different populations. If browser users degrade but synthetic tests stay healthy, client-side rendering, JavaScript, authentication, or user-specific paths may be involved. If synthetic tests degrade globally, network or application service becomes more likely.
Test accounts should be governed because synthetic credentials often need persistent access to critical applications. Use least privilege, store credentials securely, and rotate them without breaking monitoring silently.
ADEM is most valuable when support, network, security, and application teams share the same experience evidence. The platform should reduce argument about ownership by showing where the path changed, then route the incident to the team capable of fixing that segment.
Experience monitoring should have change annotations. When a Prisma Access location, routing policy, ISP, app version, or authentication provider changes, mark the timeline so later operators can correlate score shifts with known events instead of treating every change as unexplained anomaly.
Endpoint health signals should be used carefully in support workflows. A user may have poor Wi-Fi, high CPU, or packet loss unrelated to Prisma Access. ADEM helps show that evidence so network teams can avoid making cloud-side changes that cannot solve the endpoint problem.
Service-level reporting should aggregate experience by business application and user population, not only by network site. This makes it possible to prioritize an issue affecting a critical application even when only a small group of users is involved.
The monitoring program is mature when ADEM findings can trigger the right operational action—endpoint support, ISP escalation, Prisma Access investigation, or application-team response—without manual guesswork.
ADEM should be included in post-change validation for upgrades and policy migrations. Comparing experience before and after a PAN-OS, Prisma Access, routing, or decryption change can identify regressions that component-level health checks miss.
Dashboards should distinguish user-count impact. A severe score drop affecting three lab users is different from a moderate degradation affecting an entire contact center. Prioritization should combine quality severity with affected population and application criticality.
Keep monitoring coverage aligned with user populations as remote sites, mobile-user groups, and applications change; an experience dashboard is only as reliable as the endpoints and tests that still represent production traffic.
Monitoring should remain aligned with service ownership and incident response. Every critical synthetic test and user-experience alert should have a target SLO, owner, escalation path, and known downstream application contact.
User-experience telemetry is most valuable when it is compared with security events and network path changes from the same time window. That lets operations teams separate an authentication or policy problem from a reachability, endpoint, ISP, or SaaS performance issue.
