
(Part 1 of 2, with Adobe and Cisco)
Introduction
I’ve been asked a few times to share the details of our Zero Trust journeys at Adobe and Cisco. Two outstanding and iconic companies where I was privileged enough to run Enterprise Security and one of many projects my respective teams were tasked with was the strategy and execution for Zero Trust.
Now, it is fair to first define “Zero Trust”—or at least what that meant to us. During our time at Adobe, we were fortunate enough to meet John Kindervag the man credited with originating the concept of Zero Trust. I think it was sometime around 2018 and during our discussion he commented that we weren't doing Zero Trust as we weren't performing packet inspection.
Of course, in my “less than humble’ reply, I blew it off and said something like we had no plans to inspect packets as it would degrade performance and the user experience. I still kinda regret my blatant disregard; that said our goal wasn't to deliver Zero Trust.
Our goal was to solve business problems, leveraging what made sense to our team following what documents and examples were available to us. Oh—and this was around 2017, which means we began at a time where the term Zero Trust was still relatively unknown. Google had gone adventurous with “Beyond Corp” and the team at Netflix were going down some similar path.
Our Definition
What were we trying to solve? I’ll dive deeper later, but here’s the TL; DR:
We defined it as: Users accessing applications and services under the assumption of an untrusted network, with both the user and device required to establish trust.
We aimed to: Improve user experience, eliminate passwords, incorporate device posture, remove VPNs, and make internal apps feel like cloud services—while simultaneously reducing risk and thwarting attacks (we’ll skip those specifics).
The Beginning
I’ve shared this before on my old Banyan Security podcast, but even as the team leader, I didn’t come up with this idea. My good friend Benzi John spent months convincing me of his vision.
Lesson for aspiring leaders: hire smarter people, listen to them, and support them (something Den Leader 1.0 never quite grasped).
Two key points from Benzi’s pitch:
- Authentication would become more complex, but passwords would be replaced with certificates.
- No more VPNs—since most employees already worked remotely (e.g., from home).
After many conversations, one finally convinced me—while carpooling from Park City to our office in Lehi, Utah. (Hard to escape a discussion when you're trapped in a car!)
The next week, Benzi asked what paperwork he needed to secure funding for a pilot. Still new at Adobe, he expected a formal process. My response? Approved. He hit the ground running—and damn, he moved fast.
Selling the Vision
Selling this vision to executives in 2017 took two attempts—the first failed, but the second left no room for rejection. I want to share both because selling a vision is often more art than science.
First, some context: Enterprise Security focused on proactive defense, while Incident Response handled reactive threats. Our goal was to collaborate—analyzing attacks and implementing strategies to counter them.
Since our teams were still forming, there was some natural tension as engineers and architects learned to work together.
Missing the Mark
For some reason, I stepped back and let the team lead the initial proposal. Maybe some took issue with my guidance on how to pitch it.
I need to stress that it is important to know your audience. The team had little experience presenting strategies to my boss, and it showed. Despite my feedback, they created a technically sound but poorly framed pitch. They used the castle-and-moat analogy, arguing that firewalls fail because social engineering allows attackers inside.
The lesson? Technical brilliance alone isn’t enough—it’s about the wrapper. Let me explain…
The Perfect Pitch?
Okay, maybe not perfect, but…
Key takeaways for a strong pitch:
- Know your audience and what resonates emotionally.
- Simplify the problem statement and highlight the solution.
- Emphasize how the user experience will improve.
- Avoid asking for excessive funding or resources.
- Present a short timeline with quick wins.
- Make it easy for executives to say yes.
How We Got It Right the Second Time
Setup: We learned from an HR study that Adobe employees ranked frequent logins and VPN access among their top five frustrations. Since our strategy directly addressed these issues, we had a built-in business case.
Since our team managed identity and network security, we joined an Accelerated Solution Design (ASD) session with HR, IT, and Security to tackle these and other challenges. Benzi had the master plan—our strategy solved both problems, making our proposal perfectly timed.
Initially, we didn’t call it Zero Trust, but we needed a project name. After some debate, we settled on Zero Trust Enterprise Network (ZEN).
How we addressed the six key pitch elements:
- Know your audience: The CIO wanted to enhance user experience and cut costs. The CSO aimed to reduce risk and prevent attacks. Both were aware of the ASD initiative and had personally complained about login frequency—something they had grilled me on before.
- Keep it simple: Instead of overwhelming them with 16+ benefits, we focused on six:
- For the CIO:
- Improve employee experience
- Remove passwords
- Eliminate VPNs & make internal apps "cloud-like" (a term coined by the CIO)
- For the CSO:
- Use secure certificates tied to users/devices
- Enforce device posture checks at authentication
- Strengthen security for internal applications
- For the CIO:
We framed these in terms of their own daily experiences—then asked them to imagine the impact on 40,000 employees.
- Minimal funding request: We repurposed one headcount and reallocated $250K, requiring no new budget. If possible, avoid asking for large amounts upfront.
- Quick wins & timeline: Benzi and the team had built a scrappy proof of concept (POC) in weeks. Armed with real results, we outlined a plan for rapid progress—talking in weeks and months, not years.
- Show, don’t just tell: The POC demo was compelling. Seeing it in action convinced our executives far more than slides ever could.
- Make it easy to say yes: We didn’t frame this as Zero Trust—we framed it as solving business pain points. We didn’t ask for money, just a green light. Saying yes was the simplest option.
The Result
The second pitch succeeded because it was clear, concise, and included a working demo. It met technical scrutiny, had a fast timeline, and aligned with broader company initiatives. While timing helped, our well-crafted case would have won approval regardless.
The Approach
This isn’t an architecture guide—every organization has unique environments, capabilities, and constraints. A desired architecture must consider existing investments, financial resources, and available talent. At Adobe, we referenced Google’s BeyondCorp, but we didn’t have Google money, so we built a solution that fit our budget and needs.
Our approach injected an adaptive process into the login workflow, conducting a posture check, enforcing policies, and determining access based on various factors. Internal applications bypassed VPN and leveraged reverse proxies.
For architectural and technical details, refer to our whitepaper, Adobe ZEN.
The Planning
I strongly dislike endless projects that fail to deliver tangible results. Breaking problems into smaller, manageable pieces helps teams see progress, builds trust with stakeholders, and allows for quick adjustments through short sprints and retrospectives.
With a successful POC, we had a rough architecture but many unknowns. We built checkpoints into our sprints to assess progress and refine our approach. The plan focused on scaling the POC into a robust, high-capacity solution for Adobe.
Five-step deployment:
- Upgrade the POC into a test platform, then move to production.
- Pilot with our own team.
- Extend to “friends and family.”
- Expand to peer teams and larger orgs.
- Deploy company wide.
At each stage, we gathered feedback, monitored performance, and made necessary adjustments.
We also had to tackle endpoint compatibility, as replacing passwords with certificates was more challenging on certain OSs and browsers. Another challenge was identifying which apps required VPN and transitioning them to ZEN. VPN logs only showed IP addresses, often pointing to our F5 load balancers—making app tracking difficult.
Back in 2017–2018, Palo Alto Networks’ application-based firewall was still evolving, and we hadn’t fully deployed it. Looking up applications in our firewall wasn’t an option—something that has changed significantly by 2025.
Marketing and Communications
A major failing of many IT and Security teams is poor communication. Brilliant work happens behind the scenes, but employees rarely know what IT or Security actually does—except when something goes wrong. This makes marketing and communication critical. If you don’t have a dedicated team, consider creating one.
Who needs to hear the message?
- Project Team: Keep them motivated by reinforcing the vision and why it matters. Not everyone will be fully on board, so regular updates on progress and next steps help maintain engagement.
- Leadership & Sponsors: Those funding the project need regular updates to track progress, gauge success, and maintain confidence in both the initiative and the team.
- Application Teams: Communication was minimal, but notifying them about workflow changes and reduced friction built excitement.
- End Users: With 40K+ employees, mass emails weren’t feasible. Instead, we used our intranet to share updates. Since VPN-less access worked seamlessly, there was no action required from users.
Communication Strategy:
- Tailor the format to the audience—emails, intranet articles, or web-based reports. Keep it light and easy to digest.
- Adjust frequency—weekly for the project team and executives.
- Reinforce vision, mission, and timelines to keep everyone aligned on benefits.
Execution
I get bored easily, downplay challenges, and push aggressive timelines. Fast execution matters—there’s no trophy for deploying tech. The real win is scaling quickly, smoothly, and with minimal disruption. Sometimes, a three-month deployment with a slight hiccup is better than a perfect, nine-month rollout. It’s all about risk tolerance.
Our first version of ZEN was a mix of Okta, VMware, and F5 (along with a few others). We even pushed Okta and VMware to collaborate, leading to a formal integration—one we helped engineer and were the first to use.
We also built a Security Intelligence team that leveraged open-source machine learning to detect anomalies using log data. Their work fed into both ZEN and the SOC, eliminating the need for routine password resets. Instead, passwords only changed upon confirmed compromise.
From POC to onboarding 40,000+ users, 80,000+ devices, and 2,000+ applications took just seven months for V1 implementation.
Adversity and Skepticism
Today, everyone talks about Zero Trust, but in 2017–18, it was far from mainstream. We faced skepticism—some bordering on sabotage. The hardest part? Resistance from within our own organization.
Change is difficult, even for seasoned architects. If someone has spent their career relying on firewalls, packet sniffing, and segmentation, shifting away from network-based security is a tough pill to swallow. But if users no longer need to be on our network, we need a new choke point—which is exactly what our plan delivered.
A moment that stuck with me:
A senior security researcher argued, “If Mimikatz is on an endpoint, an attacker can steal the certificate,” as if proving our approach wasn’t 100% secure. But if Mimikatz is on an endpoint, it’s already game over—whether stealing a cert or a password. The real question is: Is this more secure than before?
After the project’s success, my boss gave me a glowing annual review but included one unforgettable line:
"I’m amazed this project succeeded given how many people tried to sabotage it."
A tough lesson: Even those who seem like allies can undermine you. Negative and toxic people exist, and while they may have a place on your team, be mindful of their influence.
Opportunistic Moments
Every project presents moments to push forward—if you know where to look.
For us, enabling application access without network dependency made M&A integrations a perfect use case. It just so happened we had two acquisitions, one in a high-risk country.
Since pre-close due diligence offers limited access, we used ZEN to onboard employees without connecting their network to ours—avoiding the traditional, riskier method. We simply deployed our client, assigned users to directory groups, and everything worked.
Were we fully ready? Not exactly. But the M&A timeline became a forcing function, pushing delayed decisions forward.
Lesson: Always seek opportunities that drive your project forward.
For more on Zero Trust in M&A, check out the blog I wrote as CSO at Banyan Security.
Measuring Progress and Success
We focused on six key wins:
- Improve Employee Experience
- Remove passwords
- Eliminate VPN
- Make internal apps feel "cloud-like" (a term coined by our CIO)
- Enhance Security
- Use certificates tied to users and devices
- Enforce posture checks at every login
- Strengthen security for internal applications
Beyond these, other key benefits included:
- Saving Employee Time
- No more VPN hassles
- No more mandatory password resets every 90 days
- Saving IT Time
- Reduced VPN complexity and operational costs
- ~80% fewer password-related service desk tickets
Success wasn’t just about the number of users and devices onboarded—it was also about cost savings and a better user experience.
We integrated key milestones into weekly reports and end-user updates to build trust and reinforce confidence. IT and Security teams typically hear complaints, so seeing a shift to positive feedback about the improved experience was a huge win.
Surprising Moments
A few unexpected developments stood out:
- The Okta & VMware Partnership: We had pushed for this collaboration for years. It finally happened—perhaps because they saw we’d work with other vendors if they didn’t.
- SOC Investigation: One day, the SOC opened an incident when an engineer noticed they could access internal apps without VPN. Since that had never been possible in 20+ years at Adobe, they assumed it was a security issue. The investigation led back to our project—his device had the right setup, certificates, and security posture, so access was seamless. This moment reinforced how well the system just worked. (And yes, we silently deployed everything via MDM.)
- Shutting Down Adobe’s Entire Network: But that’s a story for another blog…
V1 to V2

Our first version was built on a lean budget—no extra funds, just reallocated resources and one dedicated headcount. The goal: launch fast, deliver value, learn, and refine.
The V1 architecture required traffic to route through our network for posture checks, regardless of app location. The checks were basic, but it was a solid start.
For V2, we partnered with Banyan Security in 2019. Their cloud-native platform aligned with our vision, offering a superior posture check, policy engine, and gateway architecture. Deployment was quick, and ongoing operational costs were significantly lower. Not quite set it and forget it, but far less overhead than V1.
Key Lessons Learned
Plenty of lessons came from this journey.
People matter most. Not everyone will be on board, and I could have done more to bring people along. My focus on fast execution sometimes meant pushing ahead before the whole team was ready. I’m still working on that one.
Breaking new ground is hard. Removing VPNs and reducing firewalls reshaped careers. We should have planned better to support those affected, helping them evolve with the project.
Test, test, and test again. This wasn’t new to us, but when deploying to 40,000 people, it’s critical.
If We Had a Second Chance
Well, we did—stay tuned for Part 2: Cisco.
The Vision and Journey Ahead

I left Adobe in 2020 to lead Enterprise Security at Cisco, but the work continued.
Two key opportunities stood out:
- Turning the office network into a guest network (still underway)—I wrote about this here.
- Expanding to vendor access & BYOD. When fully managing a device isn’t an option, and VPN access isn’t trusted, this platform provides a secure alternative.
Every project risks becoming a never-ending program. We defined, executed, and closed this one. Now in continuous improvement, the team still operates and refines the platform today.
Zero Trust… or Not?
Did John Kindervag say this wasn’t Zero Trust? Yes. As the founder, his ruling carries weight.
But does implementing some Zero Trust principles without all of them mean failure? No. Just like ITSM doesn’t require following every page of the book, Zero Trust should solve business problems—not just check boxes.
References
Adobe’s Zero Trust blog post
- https://www.adobe.com/content/dam/cc/en/trust-center/ungated/whitepapers/corporate/adobe-zen-wp.pdf
- https://blog.adobe.com/en/publish/2018/05/31/achieving-network-security-zen
Okta & VMware partnership