test customer

1. Add the customer IdP in Zero Trust → Settings → Authentication; verify test login.
2. Configure it as the login method for Access applications in the POC.
3. Write an Access policy using an IdP group and a custom claim (department, role, etc.) and validate with two users (in-scope, out-of-scope).
4. Confirm MFA is enforced by the IdP and logged in Access.

Pass threshold: All POC apps authenticate via the IdP; policies resolve user, group, and one custom claim correctly; MFA events visible in Access logs.

1. For published apps: confirm TLS terminates at Cloudflare with the expected cert (Universal or uploaded custom), verify SAN coverage and chain.
2. For Gateway outbound inspection: enable 'Inspect TLS' in Settings → Network; distribute the Cloudflare cert (or custom CA) via MDM.
3. Browse a handful of test HTTPS sites from a WARP-enabled endpoint; confirm category / URL / DLP policies evaluate on decrypted traffic.
4. Add known-pinned destinations (banking, health, government) to the 'Do Not Inspect' list and confirm they bypass decryption.

Pass threshold: Published hostnames present the configured certificate; inline inspection produces policy hits on decrypted traffic; pinned destinations bypass inspection cleanly.

1. Create a Gateway HTTP policy that matches the 'Generative AI' application category (or specific hostnames: chat.openai.com, gemini.google.com, claude.ai, copilot.microsoft.com, etc.).
2. Set the action to Allow with log, and attach a DLP profile that blocks uploads containing seeded PII / source-code patterns.
3. From a test device, visit the AI destinations; confirm activity is logged per user.
4. Paste a seeded sensitive sample into the AI tool and attempt to submit; confirm the upload is blocked and the DLP incident is recorded.
5. Pull a Gateway analytics report filtered to the AI category.

Pass threshold: AI-destination activity is visible per user; DLP-matched submissions are blocked; report shows volume and user-level AI usage over time.

1. In AI Gateway, create a gateway and note the unique endpoint for the chosen provider.
2. Change the application's LLM base URL from api.openai.com (or equivalent) to the AI Gateway endpoint.
3. Send a handful of prompts from the app; confirm requests and token usage appear in the AI Gateway dashboard.
4. Enable caching and re-send an identical prompt; confirm cache hit in the dashboard.
5. Configure a rate limit or a simple guardrail; confirm enforcement.

Pass threshold: LLM calls are visible per request in the AI Gateway dashboard; caching demonstrably reduces provider calls; rate limit / guardrail fires on policy violation.

1. Zero Trust → Access → Applications → Add → Self-hosted. Configure the application domain and IdP.
2. Create a policy scoped to a test user group requiring MFA.
3. From a plain browser (no WARP / no agent), navigate to the application URL.
4. Confirm IdP redirect, MFA, and successful access.
5. Repeat with a user outside the allowed group; confirm the Access block page.

Pass threshold: Authorized user reaches the app from a clean browser in < 10s end-to-end; unauthorized user sees the Access block page with correlation ID in logs.

1. Create Gateway DNS and HTTP policies blocking representative risk categories (malware, phishing, gambling, adult).
2. From a test device, browse URLs from each blocked category; confirm the branded block page.
3. Browse a benign category and confirm it flows normally.
4. Pull the Gateway analytics report scoped to a test user; confirm per-user activity is visible.

Pass threshold: All test URLs from each blocked category are denied; per-user analytics are complete; block page is customer-branded.

1. Publish a target internal web app as an Access self-hosted application (tunnel origin).
2. For a non-HTTP target (SSH/RDP/DB), add a Private Network route in the tunnel and scope Access Private Network policies to the user group.
3. From a WARP-connected test device (in group), open the web app and the SSH/RDP session; confirm both succeed.
4. Remove the user from the allow policy; retest both; confirm both deny.

Pass threshold: Authorized user reaches both web and non-web targets with identity+posture enforced; unauthorized user has no access to any target, not just no route.

1. In the tunnel config, add two public hostnames on the same tunnel pointing at different origins (or different paths of the same origin).
2. For each public hostname, create an Access self-hosted application with a different policy.
3. From a test user, confirm each hostname routes to the intended origin with the intended policy.
4. Confirm the origin IP is not directly reachable from the public internet.

Pass threshold: Routing is strictly hostname-based; each hostname carries its own policy; origins are not publicly reachable.

1. Write a minimal Terraform config that creates: an Access application + policy, a Gateway HTTP rule, a tunnel, an IdP / SCIM integration resource.
2. `terraform plan` / `apply` and confirm all resources are created in the dashboard.
3. Change an attribute in Terraform (e.g. add a group to a policy); apply and confirm drift is detected and applied.
4. Manually change a resource in the dashboard; re-run plan; confirm drift is detected.
5. `terraform destroy` and confirm clean removal.

Pass threshold: All representative resource types are managed by Terraform with clean create / update / drift-detect / destroy. Provider documentation covers every resource used.

1. Create Logpush jobs for Access, Gateway DNS, Gateway HTTP, Audit, WARP, and DNS Firewall (as applicable) to the target SIEM.
2. Trigger representative events: successful login, denied login, blocked URL, policy change.
3. Confirm events arrive in the SIEM within the documented delivery window and parse against the published schema.
4. Confirm admin-change events appear in the Audit stream.
5. Validate retention matches customer policy (Logpush supplies the events; retention is configured in the SIEM side).

Pass threshold: All enabled event types arrive in the SIEM with expected fields parsed; admin-change events are present; delivery meets Cloudflare's documented timing.

1. In Notifications, create policies for at least three critical event types: tunnel health, WARP client health / posture, Access policy changes, certificate expiry.
2. Route each policy to the chosen channel (email / webhook / PagerDuty).
3. Trigger each event (stop a tunnel replica for tunnel-health, change a policy to test admin-change).
4. Confirm each notification arrives on the expected channel within the vendor's documented timing.
5. Adjust filters to reduce noise; confirm only intended events still alert.

Pass threshold: Each configured alert fires on the correct event, reaches the target channel within documented SLA, and can be tuned without losing signal.

1. In Zero Trust → Settings → WARP Client → Device posture, enable the MDM provider integration (Intune / JAMF / Kandji / etc.) and configure the compliance signal.
2. Add a 'Require' rule on the Access application under test for: MDM enrolled + compliant.
3. From an MDM-enrolled, compliant test device, validate access succeeds.
4. Either unenroll the device, mark it non-compliant in MDM, or remove the device certificate. Verify each scenario independently blocks access with a clear user message.
5. Re-enroll and validate re-admission.

Pass threshold: Non-enrolled / non-compliant device is blocked regardless of user identity; compliant device is admitted; Access log shows which posture check failed.