ZTNA (Zero Trust Network Access) Selling to the Network Architect — 60-Min Training

The outcome you should expect

A 60-minute training built around this motion changes three measurable things in a seller's ZTNA pipeline, and it is worth being precise about which three, because vague enablement produces vague results.

The first is discovery depth on the technical persona. Before the training, most sellers treat the network architect as a technical validator — someone the sales engineer handles after the CIO says yes. After the training, the architect is a primary discovery target with their own question set, and the AE can hold a fifteen-minute conversation about round-trip time, path selection, split tunneling, and identity-provider federation without handing the call to an SE. The observable proof is call recordings: architect-specific questions appear in the first or second meeting rather than the fourth, and the SE's role shifts from translating to validating.

The second is deal shape. ZTNA purchases are largely funded by reallocating existing remote-access budget — SSL-VPN concentrator licenses, the appliances themselves, dedicated circuits, and the engineering hours spent maintaining them. That means the seller who frames the deal as new security spend is competing against every other security line item for a fixed pool, while the seller who frames it as a substitution is competing against the incumbent VPN's renewal inertia. Those are different fights with different win rates. Training the substitution frame moves the conversation from "why now" to "what does the cutover look like," which is a much easier conversation to advance.

The third is cycle predictability. Enterprise ZTNA cycles stall in two predictable places: the proof-of-concept that never produces a decision-grade number, and the timeline that slides past the incumbent's auto-renewal. Both are avoidable with structure. A POC with pre-agreed success criteria and a real user cohort produces a number the architect can defend internally. A cutover plan anchored to the incumbent renewal date creates a real deadline that isn't manufactured by the seller.

What the training does not produce is a shortcut past the security review. The CISO's data-classification and lateral-movement questions still take the time they take. Sellers who expect the architect's technical approval to carry them through security review will be surprised. The realistic outcome is a cycle where technical validation and security review run in parallel rather than in sequence — which is where most of the compression comes from.

Set expectations with the room honestly at the top of the hour: this training will not make a bad-fit deal close. It makes good-fit deals legible faster, and it kills bad-fit deals earlier, which is the more valuable of the two effects for a team carrying a large-ACV quota.

What drives that outcome

The mechanism is straightforward once you name it. Network architects buy on operational evidence, and the seller who produces operational evidence earliest becomes the reference architecture the other vendors get measured against.

Latency is the architect's native language. An architect does not evaluate "zero trust" as a concept — they have been told for three years that every vendor delivers it. What they evaluate is whether traffic from a user in a given metro to an application in a given cloud region gets faster, slower, or stays the same, and whether the path is predictable enough that they can explain a bad day to their director. In discovery, ask them to pull their own measurements for three critical applications: the branch or remote user's round-trip time to first byte, the P95 rather than the average, and the variance across their two or three largest user concentrations. If they can't produce those numbers, that's an even better opening — offer to help them measure, because the vendor who instruments the baseline owns the scoreboard.

The comparison must be on their applications, not your reference architecture. Generic vendor benchmarks are dismissed on sight, and rightly so — they measure a synthetic path under favorable conditions. The demo that moves an architect is a side-by-side on the application their help desk gets tickets about, from the metro where most of their users sit, during their business hours. This is more work than a canned demo. It is also the entire difference between a technical evaluation you lead and one you're a participant in.

Identity coverage is a pass/fail gate, not a differentiator. Every enterprise runs a primary identity provider and a long tail of legacy authentication — an on-premises directory with Kerberos-based delegation, a handful of applications wired directly to SAML, service accounts that predate anyone in the room. The architect's real question is not "do you support Okta" but "what happens to the seventeen applications that don't speak modern auth." Find the long tail during discovery. A ZTNA that handles the primary provider beautifully and fails the legacy tail loses at the proof-of-concept stage, and it loses late, after you've invested a quarter.

Displacement velocity is the CIO's number and the architect's risk. The CIO wants to know when the VPN line item disappears. The architect knows that decommissioning the last twenty percent of concentrators is where the pain lives — the manufacturing site with a hardcoded IP, the vendor VPN tunnel nobody documented, the multicast application that predates the current network team. Both concerns are legitimate. The training's job is to make the seller comfortable holding both at once rather than promising a clean cutover that the architect knows is fiction.

The diagram is also the coaching rubric. In roleplay, stop the rep at each decision node and ask what evidence they have to move forward. Most reps skip straight from the first call to POC scoping without a baseline and without the identity long tail, which is precisely why their proofs of concept produce debates instead of decisions.

Benchmarks and realistic ranges

Be careful here, because this is where sales training most often manufactures numbers. Use ranges the room can verify against their own closed-won history rather than industry statistics nobody in the room can check.

Deal size. Enterprise ZTNA and secure-access-service-edge deals commonly land in the low-to-mid six figures annually for a mid-sized enterprise and reach seven figures for large multinational deployments with broad application coverage. Pricing is predominantly per-user per-year, sometimes bundled into a broader platform subscription. The practical training point: per-user pricing is easier to defend in a finance review because it scales with a number the CIO already forecasts, whereas bandwidth-based pricing invites a modeling argument the seller usually loses.

Cycle length. Enterprise cycles that include a real POC and a security review rarely close inside a quarter. Plan for two to three quarters from first architect meeting to signature, with the long pole being either the security review or the budget cycle rather than the technical evaluation. Sellers who forecast a one-quarter close on a platform displacement are almost always modeling a renewal date, not a decision process.

POC duration. A proof of concept short enough to avoid capturing a support-ticket trend is a proof of concept that produces no operational evidence. Run long enough to cover at least one full business cycle for the user cohort — typically several weeks minimum — and long enough to include a bad week. Architects trust numbers that survive a bad week. A two-week sandbox POC with synthetic traffic tells the architect nothing they'll repeat to their leadership.

Cohort size. A representative cohort matters more than a large one. Pick users across the two or three largest geographic concentrations, include at least one branch or manufacturing site if they have one, and include the applications that generate help-desk volume. A hundred users spanning real conditions beat a thousand users all sitting in one headquarters.

Displacement expectations. Set the honest range. Most organizations retire the bulk of user-facing remote access within the first year and then spend considerably longer on the residual cases — site-to-site tunnels, third-party vendor access, and applications with hard network dependencies. Coach sellers to say this out loud. An architect who hears "full VPN elimination in six months" discounts everything else you said; an architect who hears "user access first, then we'll work the exception list together" believes you've done this before.

Application onboarding. Onboarding rate depends almost entirely on whether the applications are already fronted by modern authentication and whether the customer has clean inventory. A customer with a maintained application catalog and a standard identity provider moves fast. A customer discovering their own application inventory during the project moves slowly, and no tooling fixes that. Ask about inventory maturity in discovery — it's the single best predictor of implementation timeline and therefore of reference-ability.

What to avoid quoting. Do not cite precise market-wide percentages for budget reallocation, latency improvement, or displacement rates unless you can hand the architect the source document. Architects check. A seller caught inflating one number loses credibility on every other number they've given, including the ones that were accurate. The training should explicitly ban unsourced statistics from the room's talk track — replace them with "here's what we measured in your environment," which is stronger anyway.

Risks, edge cases, and failure modes

Half of this hour should be spent on what goes wrong, because these deals fail in recognizable patterns and recognizable patterns are coachable.

The sandbox proof of concept. A POC run in an isolated test environment with synthetic users measures nothing the architect cares about. It produces a slide deck, not a decision. If the customer insists on a sandbox first for security reasons, accept it as a gate but insist on a second phase with real users before any success criteria are declared met. Write the two-phase structure into the POC agreement so it isn't a negotiation later.

The single-region proof. Testing only from headquarters proves the easy case. The architect's actual anxiety is the user in a distant region reaching an application hosted somewhere else, where path selection and edge coverage matter most. Deliberately include the hardest geography in the test. Winning the hard case is worth more than winning three easy ones, and losing it during the POC is far better than discovering it in month four of production.

The procurement-only meeting. A meeting with procurement and no technical or executive presence is a price-extraction exercise, and the seller has nothing to trade. Decline politely and offer a joint session. The framing that works: the commercial structure depends on scope and timeline, and scope and timeline are decisions the architect and CIO own, so we should have them in the room. This is not a hard rule to enforce if the technical relationship is real — and if it isn't, the procurement-only meeting was going to end badly regardless.

Timeline slipping past the renewal. Incumbent renewals frequently carry notice-period requirements, meaning the practical decision deadline sits well before the contract end date. Find the renewal date and the notice window in discovery and work backward. A seller who discovers the notice period after it has passed has lost the cycle to inertia and will be told to come back next year — which usually means a fresh evaluation against a now-entrenched incumbent.

Overselling the security story to a network audience. The architect has sat through the zero-trust pitch from every vendor in the category. Repeating it signals you have nothing specific. Lead with operations — path behavior, failure modes, observability, what happens when the edge location nearest their users has a problem, how they troubleshoot a slow application without opening a support ticket with you. Architects care intensely about whether they can diagnose problems themselves.

Ignoring the non-user traffic. Site-to-site connectivity, machine-to-machine traffic, and third-party vendor access frequently sit inside the same VPN infrastructure the deal proposes to displace. If the ZTNA product doesn't address those, say so early and scope them out explicitly. The failure mode is a deal that closes on a user-access promise and then gets relitigated in implementation when the architect discovers the manufacturing tunnels are still on the old box and the budget assumed they wouldn't be.

The absent CISO. Technical approval from the architect does not survive a security review that started late. Get the CISO's data-classification and logging requirements in front of the team during the POC, not after. Security reviews rarely block deals outright; they delay them by a quarter, which for a seller carrying a number is functionally the same thing.

Single-threading on the architect. The architect can pick the platform and cannot fund it. A cycle that lives entirely on the technical relationship dies when the architect changes roles or when the budget conversation arrives without an executive sponsor who has been briefed. Multithread deliberately, and give the architect something to carry upward — the measured latency comparison is exactly that artifact.

A practical rollout plan

Here is how to run the sixty minutes and what happens after, because a training that ends when the hour ends changes nothing.

Minutes 0–5, frame the motion. State the thesis plainly: this is a substitution sale into an operational buyer. Write the three buyers on the board with their actual questions — the CIO asks when the old line item goes away, the network architect asks whether users get a better experience and whether they can operate it, the CISO asks what the access policy and audit trail look like. Every rep should be able to recite which question belongs to which person by minute five.

Minutes 5–20, the architect discovery script. Work through the question set as a group before roleplaying it. Current remote-access architecture and its annual run rate. Measured user-to-application round-trip time for the three most-used applications, at P95. The two or three largest user concentrations geographically. Identity provider primary and the legacy authentication long tail. Whether site-to-site and vendor access ride the same infrastructure. What they currently cannot troubleshoot without vendor help. Incumbent renewal date and notice window. Application inventory maturity.

Minutes 20–35, paired roleplay. Split into pairs, one plays the architect and one sells. Run the discovery twice with roles swapped, eight minutes each. The person playing the architect should push back the way a real one does — skeptical of vendor benchmarks, focused on failure modes, uninterested in the security narrative. Debrief for four minutes on where reps reached for a generic claim instead of a question.

Minutes 35–47, the proof-of-concept design. Take one real opportunity from the room's pipeline and scope its POC live. Define the cohort, the geographies, the applications, the measurement method, the duration, and the written success criteria. Make the room argue about what number would actually cause the architect to recommend a purchase. If nobody can name it, the POC isn't designed yet — which is the lesson.

Minutes 47–56, the cutover timeline. Build the timeline backward from the incumbent renewal notice date on a shared screen: proof of concept, pilot, phased rollout by user population, residual-case cleanup. Show it as a simple sequence the architect can take to their director. The realism is the point — a plan that admits the messy tail is more persuasive than one that doesn't.

Minutes 56–60, commitments. Each rep names one open opportunity, one architect they will schedule with in the next two weeks, and the one measurement they'll ask for. Write them down. The manager reviews them in the next pipeline session.

After the hour. The training has no effect without follow-through in two places. First, call review: pull one architect conversation per rep in the following two weeks and score it against the discovery script — did they get the baseline numbers, did they find the legacy authentication tail, did they get the renewal notice date. Second, opportunity inspection: for every ZTNA deal in the forecast, require the measured latency comparison and the written POC success criteria as advancement evidence. Deals without those artifacts get forecast one category lower until they have them. That single inspection rule does more for Selling discipline than the Training hour itself; the hour teaches the motion, the inspection makes the team run it.

Related questions

Should the sales engineer or the AE run the architect conversation?

The AE runs discovery; the SE validates. If the AE cannot hold fifteen minutes on latency, path behavior, and identity federation, the architect relationship belongs to the SE by default — which makes the deal fragile when the SE gets reassigned.

How do you handle an architect who says every vendor claims the same thing?

Agree with them, then stop claiming. Offer to measure their actual environment jointly and give them the numbers regardless of outcome. The vendor who instruments the baseline sets the comparison everyone else gets judged against.

What if the customer wants to keep their VPN alongside ZTNA?

That is the normal end state for a while. Scope user access first and put site-to-site, vendor, and legacy-dependency traffic on an explicit exception list with owners and dates. Pretending otherwise creates an implementation dispute later.

When is a ZTNA opportunity worth disqualifying?

When there is no measurable user-experience problem, no renewal event within the planning horizon, and no executive sponsor — three absences together mean an evaluation, not a purchase. One absence is workable; all three is a year of activity with no decision.

How much of the hour should be roleplay versus lecture?

At least a third. Reps do not learn a question sequence by hearing it. The paired discovery block is the part that changes behavior on live calls; the lecture portions only set up what the roleplay practices.

FAQ

Who should attend this 60-minute session?

Enterprise account executives carrying network or security territory, the sales engineers paired with them, and the frontline manager who will inspect the resulting opportunities. Channel sellers benefit if partner-led deals reach the same technical buyer. Keep the room small enough that everyone roleplays — roughly eight to twelve people is the practical ceiling for a single hour.

Why focus the training on the network architect rather than the CISO?

Because the CISO's approval is usually necessary but not sufficient, and most sellers already know how to run a security conversation. The architect decides whether the platform is operable, and that judgment is what turns an approved concept into a selected vendor. Sellers who neglect the architect find their deals technically stalled after executive enthusiasm.

How do you compete when the incumbent is already deployed?

On operational evidence and timing. Measure the incumbent's actual added latency and troubleshooting burden on the customer's own applications rather than arguing feature lists, and align your evaluation timeline to their renewal notice window so switching is a live option rather than a hypothetical one.

What sales methodology does this pair with?

Any qualification framework the team already uses works — MEDDPICC-style qualification and value-messaging frameworks such as Command of the Message both map cleanly onto this motion. Do not introduce a new methodology inside this hour. The training teaches a persona-specific discovery sequence that plugs into whatever the team already runs.

How is the training measured?

Through call review and opportunity inspection, not a completion certificate. Score architect conversations against the discovery script for two weeks afterward, and require the measured latency comparison plus written POC success criteria before any ZTNA deal advances in the forecast. Those two artifacts are the observable output.

Can this be run remotely?

Yes, with one adjustment — roleplay needs breakout rooms, and the facilitator should drop into each one. Remote sessions tend to compress the practice block first, which is exactly the block that produces behavior change. Protect the fifteen roleplay minutes even if it means cutting the framing segment short.

Sources

• https://www.nist.gov/publications/zero-trust-architecture
• https://csrc.nist.gov/pubs/sp/800/207/final
• https://www.cisa.gov/zero-trust-maturity-model
• https://www.gartner.com/en/information-technology/glossary/zero-trust-network-access-ztna
• https://learn.microsoft.com/en-us/security/zero-trust/
• https://www.ncsc.gov.uk/collection/zero-trust-architecture
• https://cloud.google.com/beyondcorp
• https://www.rfc-editor.org/rfc/rfc7642
• https://openid.net/developers/how-connect-works/

Related on PULSE

• [Privileged Access Management (PAM) Selling to the CISO — 60-Min Training](/knowledge/st390)
• [CNAPP Selling to the Cloud Security Architect — 60-Min Training](/knowledge/st402)
• [Cloud Security Posture Management (CSPM) Selling to the Cloud Architect — 60-Min Training](/knowledge/st391)
• [The Value Presentation Architect: A 60-Minute Workshop Template for Sales Decks](/knowledge/st0668)
• [Top 10 executive access role-play scenarios for sales teams](/knowledge/st0558)
• [Top 10 executive access training drills for B2B sales reps](/knowledge/st0557)