Cloudflare Customer Engineer (CE) Technical Onboarding Program

1. The role: Customer Engineer, technical lifecycle owner

Every technical hire is a Customer Engineer. The title supersedes Sales Engineer, SE, and any prior variant. There is one onboarding path — no pre-sales/post-sales fork, and no separate AppSec track. Tenured engineers assume the same scope, so this program serves two populations: new hires (§8) and converting engineers (§13).

The CE owns the technical lifecycle of the in-scope products:

discovery → qualification → demo → PoC → value case → commercial handshake → onboarding & delivery → tuning & optimisation → initial troubleshooting & escalation → adoption & renewal support

Ownership is of the technical lifecycle, and it is continuous: you bring in help, you do not hand off the customer. Depth is tiered because a support pod of Customer Engineering Specialists (CES) provides technical depth and expertise (§5). Four structural consequences:

1. Post-sales is core, not a delta. The part you need on day one is inside the core (Week 6); the part that matters at month three sits in the second phase.
2. Every product is taught through a lifecycle lens (§3), not as a pre-sales pitch. Knowing how to sell WAF is half the job; deploying it, tuning it and unbreaking it is the other half.
3. PoC scoping and Salesforce hygiene are firmly in scope. They were explicitly out of scope in the prior AppSec curriculum — defensible for a pure pre-sales role, untenable for technical lifecycle ownership. They are taught in the second phase rather than the core, because they are not needed to own a Tier 1 account.
4. You are the technical continuity. The old model handed customers between roles. This one does not, which makes your written record — handshake notes, SFDC commentary, onboarding docs, troubleshooting findings — the thing that protects the account when coverage changes.

Naming rules

• CES = Customer Engineering Specialist. The abbreviation belongs to the role.
• Cloudflare Email Security is always written in full and never abbreviated, because it shares those initials. Any "CES" in this program means a person, not a product.
• Role references use "Customer Engineer", "CE" and "CE Buddy". Existing artefacts keep their original names so they stay findable — the SE Onboarding Account Access wiki, the SE Bookmark Library, the SE/CSE Bootcamp, the Solutions Engineering — Product Updates deck, the Cloudflare SE Team GCP project, the se@cloudflare.com group, the solutions-engineering JIRA group, and the Hive's session titles. Renaming those is a separate migration (D10).

2. Design principles retained from Mike Stone

1. Foundation before breadth. Core (Act I / Act II) services first, then Cloudflare One and Developer Platform later — deliberately. The two-phase structure strengthens this: Tier 2 sits outside the core entirely.
2. Don't compress the foundation. Mike Stone's finding was that a rushed program risks setting new colleagues up for failure. Weeks 1–5 are his Tier 1 sequence, untouched. The core got shorter by moving material out — troubleshooting tools, PoC, BVA, competitive, SFDC hygiene and SSL for SaaS — not by squeezing the product weeks.
3. Scope guardrails over completeness. An explicit out-of-scope list is a feature, and so is an explicit not-yet list. Lifecycle ownership applies to the in-scope set; depth stays tiered; excluded products become optional ongoing training (§4).
4. Guest-speaker SME model. Load-balance mentor time, get multiple voices heard, give team members reps at presenting, and avoid committing one person for two months.
5. Reading is a jumping board, not a mandate.
6. Shadowing is continuous and opportunistic — now across the whole lifecycle, not just discovery.
7. Work in progress by design. The dashboard evolves, best practices shift, features never stop. The structure is what should be durable.

3. The lifecycle lens

This is the main mechanism by which lifecycle ownership is taught rather than announced. It extends Mike Stone's product framing and the CE checklist's module rubric across the back half of the lifecycle.

For every product module, you should be able to cover all nine:

1. How it works behind the scenes
2. The customer pain it solves
3. Our competitive advantage
4. Its limitations and gotchas
5. The discovery questions that qualify it in or out
6. Provisioning and onboarding steps
7. Tuning levers and common failure modes after go-live
8. How to run initial troubleshooting on it, who to consult, and when a Support ticket is appropriate
9. Adoption signals — what "healthy" looks like, and what to watch before renewal

Items 7–9 are new. They are the difference between the former SE scope and the CE scope, they are the standard every presentation and certification gate is held to, and they are the core of the conversion path for tenured engineers (§13).

4. Scope

Technical lifecycle ownership is complete for the core set below. Product depth is tiered, and the tiers mirror the support pod's domains exactly (§5). You learn to 101/102 precisely where a Specialist backs you up. The tiers are also what makes a 7-week core possible (§7).

Tier 1 — core, full lifecycle ownership, no specialist domain behind you

DNS · SSL/TLS · Caching · DDoS · WAF (managed + custom) · Rate Limiting · API Shield · Page Shield · Bot Management (including the Turnstile and mobile app protection discussion) · Rules engine · Speed & Optimization · Spectrum · Load Balancing · Waiting Room · Custom Pages · Analytics & Logs · Logpush · Version Management · Network · Traffic · SSL for SaaS (taught in the second phase)

This is the set you must sell, deploy, tune, troubleshoot and renew on your own. The 7-week core is devoted to it, with SSL for SaaS the one deferral.

Tier 2 — 101/102 level, specialist-backed

Cloudflare One / SASE · Developer Platform (Workers, R2, KV, D1, Durable Objects, Workflows, Queues) · AI — including the distinction between AI Gateway, AI Security for Applications, and AI Crawl Control

Qualify, demo, and hold a first-line conversation. Bring in a Specialist for design depth and delivery. Taught in the second phase, not the core.

Tier 3 — awareness, specialist-led

Magic Transit · Cloudflare WAN (formerly Magic WAN) · Cloudflare Network Firewall (formerly Magic Firewall) · Network Interconnect · China Network

Know enough to judge whether an opportunity is qualified, then bring the pod in to lead technically. Mike Stone's ~10-minute Magic Transit overview deck is the right tool for that first conversation.

Tier 4 — optional ongoing training

Cloudflare Email Security · Stream · Zaraz · Images · Calls · R2 as a standalone motion · other account-level products

Excluded from both the core and the second phase by design, and offered instead as opt-in ongoing training for engineers who want or need them. Route requests through the Hive's existing enablement wishlist and mentor track — that mechanism already exists and is the natural home for this. Escalation on these products follows the standard ladder in §5.

Scope contradictions resolved

• Zero Trust appeared on both the "newly in scope" and "not in scope" lists in the Mike Stone page — a leftover from before the 22 May 2026 update. Tier 2, second phase.
• Turnstile appeared in scope as a Bot Management discussion and in the out-of-scope account-level list. Tier 1, discussion only, no demo build (D8).
• Pre-sales vs post-sales. Resolved by the retitling: one CE role, one technical lifecycle, no fork.
• Lifecycle vs portfolio breadth. Resolved: lifecycle complete, portfolio tiered, remainder optional.

5. Escalation: the troubleshooting ladder

A support pod sits outside the CE role, staffed with Customer Engineering Specialists whose domains are SASE and Cloudflare One products, Networking products, and Developer products. The pod provides technical depth and expertise; it does not take ownership. The CE remains the owner of the technical lifecycle throughout.

The three steps, in order

The standing principle

CEs have an obligation for initial troubleshooting, but must not depreciate the role Support provides.

Both halves matter, and they fail in opposite directions:

• Skipping step 1 — passing a raw symptom to Support or a Specialist — offloads work you own and burns the goodwill of functions you depend on.
• Refusing step 3 — treating escalation as personal failure and grinding on alone — is equally wrong. Support is a professional function with tooling, visibility and platform authority you do not have. Escalating after real initial troubleshooting is correct practice, not defeat.

This is a graded competency at Gate 1 and Gate A, and it is the single most common thing new CEs get wrong in either direction.

Beyond the ladder

• Product / Engineering — when you have confirmed a genuine product gap rather than a workaround, it becomes a bug or a feature request.
• Tier 3 opportunities — bring the pod in from the moment the opportunity is real, not when it is in trouble.
• Retained guardrail from Mike Stone: on Magic Transit opportunities, do not go it alone. Strongly avoid a PoC. If one is unavoidable, push for a leased Cloudflare Magic Transit IP — if the customer insists on their own /24, their block is now on our platform and becomes much harder to disable without affecting real customer traffic.

6. Delivery model

• The Hive = the classroom. Live cohort sessions, the recording and summary-notes library, office hours at the end of every session, the session feedback form, and the enablement wishlist — which now also carries Tier 4 optional training requests.
• The CE Buddy = the coach. Weekly sync, the presentation series, and gate sign-off. Buddy eligibility requires competency across all areas — see §13.
• SME guest speakers = the depth. Named owners per product area, rotating. Extended-phase Tier 2/3 weeks should be taught by the support pod — better content, and it introduces the new hire to the Specialists they will consult.
• Office hours + the mentor track = the safety net and the career path.

SME roster (Named West, carried over from Mike Stone): API Shield — Tim Uy · Bot Management — Ish Chavez · Developer — Suzanne Aldrich, Will Smithee

Acknowledged gap (G10), not a launch blocker: there is no named SME for DNS/SSL or WAF/Rate Limiting. Where an SME is missing, the core runs on the buddy plus the Hive recordings. Tier 2/3 SMEs come from the pod.

7. Structure: a 7-week core, then a second phase

The program runs in two phases. Phase 1 is the 7-week core — Week 0 plus six content weeks, all Tier 1, ending in a single readiness gate. Phase 2 is a second phase of training that runs alongside live customer work: real CE scope, but none of it needed to take first-line ownership of a Tier 1 account. Ramp expectations follow the whole program, not the core: a CE counts as productive at completion, not at Gate 1 (D21).

What the core carries, and what it does not

1. Tier 2 and 3 are out of the core entirely. Developer Platform, Cloudflare One / SASE and Networking become second-phase modules taught by the pod. This is safe because the pod exists, and it strengthens Mike Stone's "foundation first, platform later" principle rather than bending it.
2. Troubleshooting tools and method move to the second phase (G1, G2). The ladder itself is taught as behaviour in Week 6 — attempt isolation, bring evidence, then escalate — and Gate 1 grades the behaviour. Tool-by-tool fluency and the seeded-failure exercise are graded at Gate A instead. Until that module lands, initial troubleshooting is worked with the buddy rather than alone.
3. PoC, BVA, competitive positioning and SFDC hygiene move to the second phase (G3, G4, G5, G9). Firmly in scope for the role, not needed at Gate 1. The buddy leads any PoC in the meantime (D7, D20).
4. SSL for SaaS moves to the second phase (G6) — a Tier 1 product, but the Hive session and the dev docs carry it without a dedicated core slot.
5. Post-sales splits by urgency. What you need the moment you own an account — onboarding delivery, the handshake, the ladder, tuning cadence — stays in the core at Week 6. Adoption, renewal and escalation depth go to the second phase.
6. Tier 4 leaves the program and becomes optional ongoing training.

Phase 1 — Core (7 calendar weeks)

Phase 2 — The second phase of training (alongside live work)

No week numbers, deliberately. The program lead and the buddy sequence these against the new CE's live accounts; modules 1 and 2 come first. Residual risk, stated plainly: a CE takes first-line Tier 1 ownership at the end of Week 6 without the troubleshooting tools, PoC scoping, competitive positioning or SFDC discipline. That is the price of a 7-week core, and the mitigation is the buddy backstop (D20) — not a longer program.

8. The core, week by week

Week 0 — Let's Get Started: setup, access & orientation

• Run the DevTools setup script (Homebrew, cloudflared, SSH keys, internal package repos).
• Configure git with your @cloudflare.com address; install cloudflared for Access-protected internal resources.
• Enroll your mobile device — iOS or Android (optional, recommended).
• Work the access table in §10. File IT issues at the AskIT Service Portal.
• Company orientation via Workday — Day 1: laptop, welcome, security awareness, benefits/payroll. Day 2: product overview, how Cloudflare works, technical deep dive. Day 3: becoming a trusted partner, why we serve everyone, go-to-market Q&A. Then finish the on-demand orientation.
• Meet your CE Buddy, walk this program together, and take your own working copy to tick off.
• Understand the role and the escalation ladder. Read §1, §3 and §5 with your buddy. Technical lifecycle ownership and the three-step ladder are the two things new hires most often mis-scope in month one.
• 30/60/90 expectations conversation with your manager, framed on the two phases — including that productivity is measured from program completion, not from Gate 1 (G8, D21).

Gate: all access granted or explicitly deferred with a reason; buddy and SME roster confirmed; you can name your support pod contacts.

Week 1 — It's Always DNS

Objectives. DNS (full and partial setup) · SSL/TLS encryption modes and certificate types · Caching · activating a domain · dashboard access policies and RBAC · NinjaPanel free vs Enterprise · demo setup and walkthrough for DNS and certs.

Caching moved here from Mike Stone's Week 5 — it is an Application Core Service in his own scope list, the Hive teaches it on cohort day 3, and the CE checklist groups it with the core modules (D2).

Life of a Request is introduced here as the mental model every later week hangs off, and revisited in depth in Week 4 (D3).

Hands-on. Set up a test domain in CNAME mode, then convert to FULL mode and document the gotchas. Stand up a test origin. Enable and verify SSL, IP firewall rules, True-Client-IP and Geolocation headers.

Lifecycle additions. Cert renewal failure modes and expiry monitoring · what a botched CNAME-to-FULL cutover looks like from the customer's side · which DNS and TLS symptoms you can isolate yourself and which carry the fingerprints of a platform issue.

Also learn the HTTP status code classes — 1xx hold on, 2xx here you go, 3xx go away, 4xx you messed up, 5xx I messed up. You will meet others, including internal-only codes; learn them as they come up.

Reading. DNS, SSL/TLS and Fundamentals dev docs · zone setup (full/partial) · dashboard RBAC · Universal SSL blog · Solutions For Dummies · Solutions Engineering — Product Updates deck.

Gate: can walk a customer through DNS and certificate setup unaided, and can pitch DNS + SSL/TLS.

Week 2 — Application Security Part I

Objectives. DDoS and the Cloudflare advantage · WAF (managed and custom) · Rate Limiting · the Security section: analytics, events, settings · Logpush.

Mid-week deep dive: NinjaPanel, Entitlements & Subscriptions. Entitlements control which products a customer can access; subscriptions are the newer recurring model where a bundle of features is granted and entitlements are handled automatically. Fewer products sit behind entitlements over time, but you still need it for cases like entitling Bulk Enterprise zones. Go through this with your buddy in detail (D4).

Hands-on. WAF managed rules plus custom rules; rate limit rules; verify behaviour. Practise the security benefits demo for DDoS and WAF. Practise the onboarding walkthrough again.

Lifecycle additions. False-positive triage as a discipline — the most common post-go-live WAF conversation you will have, and a textbook step-1 troubleshooting exercise · phased rollout, log mode before block mode · tuning a managed ruleset for a real application without turning it off.

Reading. DDoS, managed rules, custom rules, rate limiting, security analytics and events dev docs · Scheduled Changes for WAF (called out deliberately — it is about visibility into what Cloudflare does) · the WAF/Rate Limiting/AppSec selling wiki · the new Security Dashboard navigation guide (focus on the new dashboard, but understand the old one) · ancillary: WAF Attack Score, WAF Content Scanning.

Demo environment note. Most of us want an environment we fully control. Build your own and form your own opinions as the weeks go by.

Gate: first buddy presentation — DNS + SSL/TLS, using the template in §11.

Week 3 — Application Security Part II

Objectives. API Shield · Page Shield. Start tying onboarding and security benefits into one cohesive story rather than separate product tours.

Demo environments (use these, do not rebuild).

• API Shield — Account: Cloudflare Demo (TME), zone cf-tme.com. Kept current with live traffic, including Sensitive Data Detection. Ask your buddy for access. Known limits: you cannot create API Rules or JWT Validations, and most of the Settings tab is unavailable, so those views cannot be shown.
• Page Shield, option 1 (recommended) — Account: Burrito Bot, zone page-shield.theburritobot.com. Ask your buddy.
• Page Shield, option 2 (see it yourself) — build your own on Workers following the Turnstile-on-Workers tutorial, then the Page Shield sample pages. Workers is Tier 2 and formally out of scope until the Developer Platform module, but it is useful here. This option lets you edit policies and show how they generate CSP response headers.

Lifecycle additions. Schema learning and drift after go-live · what happens when a customer ships an API change and breaks their own validation · CSP policy maintenance as an ongoing customer task, not a one-off.

Reading and walkthroughs. API Shield and Page Shield dev docs · GraphQL protection limitations · competitive API Shield enablement · Advanced Rate Limiting and Cookie Monitor blogs · Humair's 18-minute API Gateway walkthrough and the 3-minute refresher · the App Sec Part II sample demo deck and recorded dashboard walkthrough.

Gate: can pitch the benefits and use cases of API Shield and Page Shield, and can qualify an API opportunity in or out.

Week 4 — Application Security Part III

Objectives. Bot Management (including Turnstile and mobile app protection as a discussion) · Custom Lists · Life of a Request in depth.

Lifecycle additions. Bot score tuning and the cost of a false positive on a login or checkout flow · allowlisting legitimate automation and partner traffic · list hygiene over time.

Reading. Block AI bots and crawlers blog · Hostname, ASN and IP lists blog · Cloudflare's fraud / ATO customer development plan · The Life of a Request Museum.

Gate: second buddy presentation — Caching + Rules engine. Mid-core manager check-in.

Week 5 — Manipulating requests, performance & traffic

Objectives. Rules engine · Speed and optimization · Spectrum · Load Balancing · Waiting Room · Custom Pages.

Rules engine, in full — Configuration Rules, Origin Rules, Transform Rules (URL rewrite, header modification, managed transforms), Cache Rules, Snippets, Redirects (single and bulk), Cloud Connector. These replace the legacy Page Rules — teach them as the default, not as an upgrade path.

Hands-on. Create Configuration Rules, Transform Rules (header modification), Cache Rules and a Redirect Rule — then verify precedence and execution order. Set up Load Balancing with health checks, active-passive failover and geo-steering; understand the steering types.

Lifecycle additions. Rule sprawl and precedence collisions in a mature account — the most common cause of "Cloudflare broke my site" · origin health check tuning and flapping · Waiting Room capacity planning before a real event.

Secondary. Demo Bot Management. Learn to navigate the dashboard to show the Cloudflare experience versus competitors — one-click enablement is the point. Hold a working view of Life of a Request: DDoS → Rules → Bots → WAF → onward.

Reading. Speed, Rules, Spectrum, Load Balancing (plus reference architecture), Waiting Room, Cache and Custom Pages dev docs · Load Balancing to private IPs, L4/LTM load balancing, end-to-end private traffic, Waiting Room bypass rules and analytics blogs · Load Balancing Support Guide · Waiting Room sales enablement wiki and the Waiting Room vs Imperva comparison.

Gate: third buddy presentation — WAF + Security.

Week 6 — Lifecycle core: onboarding delivery, handshake, escalation & tuning

Why this stayed in the core. You take ownership of a live account at the end of this week, and these are the skills you need on day one. The rest of the post-sales curriculum — adoption, renewal, escalation depth — is second-phase material (G12).

• Run an onboarding. The Enterprise Onboarding Checklist Template is the playbook; the Customer Onboarding Guides are the per-feature detail. Treat an onboarding as a project with a plan, a cutover and a verification step.
• The handshake. Handshake Notes: pre-sales to post-sales. Under one CE role this is largely a handoff to yourself — which makes the discipline harder to maintain and more important, since it is what protects the account when coverage changes.
• Tuning cadence. What a post-go-live tuning engagement looks like across WAF, bots, caching and rules. Pull together the lifecycle additions from Weeks 1–5.
• The escalation ladder in practice. Work §5 against real cases. Practise both failure modes deliberately: the escalation that arrives empty-handed, and the one that should have been filed a week earlier.

Shadowing checkpoint. By now you should have shadowed discovery, an onboarding, and a tuning/troubleshooting call. PoC kickoff and a live escalation wait for the second phase.

Gate: fourth buddy presentation — a full lifecycle scenario, discovery through solution to onboarding plan to life after go-live.

GATE 1 — Tier 1 customer-ready (end of the core)

Buddy sign-off that you can, on Tier 1 products only:

• explain Cloudflare's Anycast network architecture to a customer
• run a technical discovery / qualification call
• onboard an Enterprise customer unassisted — DNS, SSL, Caching, WAF, Rules engine
• perform basic performance and security tuning
• make a real first attempt at the three things you will actually be handed — cache not working, SSL errors, WAF false positives — with your buddy as backstop (full tool fluency is graded at Gate A)
• follow the escalation ladder correctly in both directions — neither passing on a raw symptom nor grinding on alone past the point a ticket was warranted

On passing: you take first-line ownership of live Tier 1 accounts, with your buddy as backstop — supervised practice, which is what makes the second phase work. This is not the productivity line (D21): ramp targets, quota and a full account load start at program completion, not here. Tier 2 and 3 opportunities go to the pod until the relevant second-phase module is complete; any PoC is buddy-led until module 2; initial troubleshooting is worked with the buddy until module 1 (D20).

9. The second phase

Everything below is real CE scope that is not required to own a Tier 1 account. It runs alongside live customer work in whatever order suits the new CE's accounts — no week numbers — with modules 1 and 2 scheduled first and certification closing the program. SSL for SaaS moved here too and needs no module: the Hive session (Jun 24) and the dev docs cover it.

Module 1 — Troubleshooting & tool fluency

Schedule this first. Step 1 of the escalation ladder is your obligation from Gate 1 and Week 6 teaches the behaviour; this module is where the tools and the method get taught properly. The CE checklist required troubleshooting as a certification criterion and listed eleven internal tools as bookmarks, but nothing taught them; the Hive teaches both live (G1, G2). Until this module is done, you work initial troubleshooting alongside your buddy.

Objectives. A repeatable initial-troubleshooting method for the three things you will actually be handed — cache not working, SSL errors, WAF false positives — and the fluency to produce evidence, not just a symptom.

• TraceGen — generate test traffic and trace requests through the stack
• Rulesets Admin — inspect and debug WAF, transform and cache rulesets
• Flute — request inspection · Bushbaby — zone configuration inspection
• Backstage Status and Backstage Toolkit · Support Dashboard
• Demo Tools · Labs Catalog · Backstage account creation · GCP Codex

Reference material to internalise. API & Tech Specs and Limits · Entitlements & Feature Flag Cheatsheet · Interoperability Table · Customer360 / Lighthouse.

Gate: resolve a seeded broken zone unaided — wrong cache behaviour, a TLS misconfiguration, and a false positive — and write the escalation you would have filed, to the standard in §5 step 3.

Module 2 — Front of the lifecycle: discovery, PoC, BVA, competitive, SFDC

In scope for the role, deliberately out of the core. PoC scoping and Salesforce hygiene were explicitly out of scope in the Mike Stone curriculum — reasonable for a pre-sales AppSec SE, mandatory under technical lifecycle ownership. They are simply not needed to pass Gate 1 (G3, G4, G5, G9; D7).

• Technical discovery and qualification — running the call, not just attending it.
• PoC process and scoping — customer-built success criteria, the PoC DSR, and what "done" means. You are scoping a PoC you will personally deliver and then support.
• BVA and BVA Lite — quantifying value, and when the lite version is enough.
• Salesforce hygiene — opportunity commentary, technical validation notes, keeping the record honest. Needs a content owner.
• Competitive positioning — only fragments exist today (Waiting Room vs Imperva, API Shield competitive reading, Catchpoint for tests against Fastly). Needs a real module and an owner.

Gate: lead a discovery call with your buddy as backup, and scope a PoC end to end. You may now lead PoCs on Tier 1.

Module 3 — Developer Platform + AI (Tier 2, pod-taught)

Objectives. Workers and the AI Developer Platform at 101 level — Workers, R2, KV, D1, Durable Objects, Workflows, Queues.

A guided session run hands-on with your CE Buddy, ideally co-delivered by a Developer-domain Specialist. It runs slightly long because of the content volume. There is required pre-session homework — do it before you attend. Materials: the mentee session link, the accompanying PDF, and the lab link (save the lab for the second half of this module).

SMEs: Suzanne Aldrich, Will Smithee.

Then the lab. Tie those concepts into a working lab environment you can demo. Required pre-session homework first. You have a mentor — let them sherpa you to the finish line.

AI agent setup (from the CE checklist — retained in full; the newest and least duplicated material of the three sources):

• Explore CloudflareOS — recommended for non-engineer-friendly agent workflows.
• Optionally set up OpenCode for terminal-based workflows, and review the OpenCode agent-rules best practices.
• Build an LLM chat app from the Cloudflare template as your first agent project.
• Put AI Gateway in front of it and configure: Guardrails · DLP policies · Logging · Spend limits · Access integration.

Be able to draw the distinction between AI Gateway, AI Security for Applications, and AI Crawl Control. Customers conflate them.

Gate: a working, demoable lab environment of your own.

Module 4 — Cloudflare One / SASE 101–102 + Networking awareness (Tier 2/3, pod-taught)

Note: Mike Stone's Zero Trust page is a placeholder ("Starting Point -"). This week is reconstructed from the Hive sessions and the CE checklist (G7), and should be delivered by SASE- and Networking-domain Specialists.

Tier 2 — Cloudflare One / SASE. Access · Gateway · Cloudflare One Client (formerly WARP) · Cloudflare Tunnel · Browser Isolation.

Tier 3 — Networking, awareness. Cloudflare WAN, Cloudflare Network Firewall, Magic Transit, Network Interconnect. Use the ~10-minute Magic Transit overview deck to test whether the story resonates, then bring the pod in to lead.

Meet your escalation partners. This week should end with you knowing, by name, who to consult in each pod domain.

Gate: can qualify a Cloudflare One opportunity, and can state precisely where your own depth ends and a Specialist's begins — while remaining the technical lifecycle owner.

Module 5 — Adoption, renewal & advanced escalation

The back half of the post-sales curriculum, out of the core because it matters at month three rather than day one (G14).

• Adoption signals. Read a customer's footprint in Customer360 / Lighthouse and spot under-adoption before it becomes a renewal problem.
• Renewal support. Support the renewal technically. BigQuery is genuinely useful here — for renewal conversations specifically, not as a routine habit.
• Escalation depth. Complex multi-product incidents, working the ladder under time pressure, and driving a confirmed product gap into a bug or feature request.
• Advanced tuning. Mature accounts with years of accumulated configuration.

Shadowing requirement completed. You should now have shadowed at least one of every call type: discovery, PoC kickoff, onboarding, tuning/troubleshooting, and an escalation.

Certification & graduation — Gates A and B

Gate A — full competency sign-off by your CE Buddy. Gate 1 plus:

• scope and run a PoC against customer-built success criteria
• work the internal debug tools and resolve a broken zone unaided (module 1)
• run a post-go-live tuning engagement and work the escalation ladder in hard cases
• read an account's adoption signals and support a renewal technically
• qualify a Tier 2 or Tier 3 opportunity and consult the right Specialist at the right moment, while retaining technical lifecycle ownership

Gate B — formal certification. Complete the CE certification and any remaining Litmos / Workday modules. Gates A and B together are the productivity line — this is the point at which a CE is counted as fully ramped (D21).

Graduation actions. Buddy signs off · update this program page with what you found wrong or missing · consider writing your first Solutions blog post · submit the Hive feedback form for every session you attended · you are now eligible to be a CE Buddy (§13).