One of the things I’ve learned while working on projects is that customers appreciate pragmatic steps, clear outcomes, and as little drama as possible when rolling out Zero Trust Network Access (ZTNA). It got me thinking … How would I describe a managed ZTNA service?

Firstly, I would demystify what “managed ZTNA” really means in practice and also where self-management makes sense instead. Then I’d share how we guide customers through the ZTNA journey – from the first onboarded app to optimizations once the ZTNA service is in operation.

Deeper meaning of “managed ZTNA”

When you choose a managed ZTNA service with us, we take our portion of responsibility end to end, but not the actual ownership – you’re running your business, not us. Our responsibility is to configure endpoints, to onboard applications, translate access requirements into policies, and troubleshoot incidents. And I mean, not just on day one, but every day after. Your request can be as simple as, “These users need this app,” and we work out the details and make it run. I’d say that’s the core value: you work with experts and keep your team focused on your business.

In contrast, with an unmanaged platform (think standalone ZTNA software), your admins must learn the nitty-gritty of product specifics on their own. Additionally, they must model app behaviors, craft policies, and chase vendor support queues when a product misbehaves, which could go on for weeks if you’re not on a premium tier. Also, bug fixes could take months.

Managed ZTNA is the difference between “I’ll figure out why this isn’t working” and “Tell us the outcome you need – we’ll make it work.”

When Managed vs. Self-Managed Makes Sense

In my line of work, I see that customers’ needs depend on their environment:

• Large, distributed environments usually see the highest ROI from managed ZTNA. There are simply too many apps, user groups, and changes for IT teams to keep up with internally. It can be like trying to count traffic at a spaghetti junction.
• Smaller teams sometimes prefer self-management for control or budget reasons, and it works well for their circumstances – we still provide self-service so they can configure apps themselves whenever they want to. And yes, we’re there for them if they hit a snag.

The ZTNA journey: phased, ongoing, and measurable

We start ZTNA projects by setting expectations and mapping the journey.

Regarding expectations, in short, it’s about having all the stakeholders in one place at the very beginning of the project. We use a governance model to oversee the delivery of quality and cost effectiveness of the services provided, as well as the successful collaboration. It sets and aligns the partnership goals with business goals to continuously improve and derive value out of the partnership.

Then comes the beginning of the journey. Many customers don’t have a clean application inventory, and we don’t expect them to, so step one is to find out which apps are being used and by whom. After that, we configure endpoints that will connect to internal resources. We map access to user groups, define and link app policies (agent and browser flows). Then we onboard the first batch of apps and run a Proof of Concept (PoC) with a test cohort before we roll it out in “waves”. We iterate on policies and follow the principle of least privilege without breaking work.

This aligns with our recommended migration journey for Zero Trust adoption in four stages, where ZTNA is the backbone:

• Stage 1: Begin with third-party access and focus on critical systems.
  That’s because third parties usually have access to highly critical and specialized systems as they are responsible for maintaining them. Typically, third parties only need very specific access to single machines, not the entire company network. Access through “bring your own devices” (BYOD) is similar to third-party access, so we deal with their security in this stage too.
• Stage 2: Replace legacy VPN.
  We often see that the same users have more access privileges with VPN when working remotely than on premises. In this stage, we set up ZTNA to ensure that remote users continue having access to the network as before. As a by-product, it tends to also reduce latency as the users connect to the closest PoP.
• Stage 3: Define granular policies.
  Here we migrate managed devices incrementally from network-based access to application-based access. The whole point of this is to use small, pragmatic steps. This is often the trickiest stage, and not because it is technically complicated, but because IT departments sometimes don’t yet know all the policies they need, and it requires sorting through the details.
• Stage 4: Unify policies for remote and on-prem users.
  This is to make sure that no matter where the employees or users happen to be working and connecting from, the ZTNA policy will be universally enforced.

The result: Less disruption, more control.

Co-management without chaos.

Our approach is to listen to our customers.

Prefer to configure an app yourself? Go for it – we’ll provide the platform and guidance. Want us to take it end-to-end? We’ll own that process. Many customers run a mix of self-service for routine additions but contact our team for tricky implementations or advice on urgent matters.

What in truth goes wrong (and how we fix it)

ZTNA comes in two flavors. It can be run with an agent on a user’s device, or it can be agentless, where users can access applications from the browser. There’s a certain amount of complexity involved in the background and it can be subtle. Here, two realities often overwhelm IT teams:

1. Web app ≠ simple HTTP:
   A page that looks like HTTP may quietly rely on LDAP, Kerberos, DNS, or other backend services. Agentless access can fail until those dependencies are accounted for. With the agent path, we can accommodate more protocols directly, and even for agentless setups, we could accommodate exotic web apps by making config changes in our software. We’ve seen this happen many times – it’s not the product; it’s the app’s hidden wiring.
2. Ports and policies are easy to miss:
   A customer configures an app, whereupon the user says, “It doesn’t work.” Then the network traces show a blocked port or unexpected dependency. We pinpoint the gap by analyzing network traffic or through ecosystem insights and fix it quickly – and the customer learns what to check next time.

Day-2 operations: Where managed pays for itself

After go-live, the project work shifts from “set up” to “keep pace” with business as usual:

• Change is constant:
  Apps move from on-prem to cloud, new tools appear, and new teams arrive in the wake of mergers and acquisitions (M&A). We adapt the app configuration as needed and automatically sync users with the corresponding ZTNA groups, so people have access to apps and resources that they need for work – and only what they need.
• Incidents happen:
  When something breaks, we don’t just create a ticket; we analyze traces and isolate the point of failure (even if it’s not our environment). In one case, a customer’s application access slowed to a crawl – the root cause turned out to be a known bug in their vendor’s second-tier firewall on the path, which wasn’t fully fixed. We proved it hop-by-hop so the vendor could remediate it. That saved the customer a lot of time.
• Periodic cleanups:
  We run reviews to retire unused apps and validate that users still require access – it reduces both the attack surface and the admin overhead in the mid- and long term.

Who’s in the loop at Open Systems

For every Open Systems service, this is what’s included:

• Pre-Sales & Deployment to shape scope, timelines, and best practices.
• Designated Technical Account Managers (TAMs) as your single point of contact – they know your network and context, which makes problem-solving faster and decisions safer.
• Mission Control Operations Center for 24×7 operations and incidents, for example why an application is not working.
• Self-service tools in the customer portal for quick and straightforward changes.
• Community forums to swap lessons learned among customers.

Why customers tell us it’s different

Talking to customers, and listening, is a primary part of my job. They give us feedback freely and matter-of-factly on project work and also about how they perceive our company.

• Feature influence:
  Because we are not a huge cybersecurity enterprise, our customers’ voices have power. We also aggregate requests across customers, so they have more leverage with third-party ZTNA software providers than any one company alone.
• Security lifecycle handled:
  Agents and components stay current – we test updates for interoperability before rolling them out, so you get protection without outages. Self-managed teams often “patch first, test later” or even never patch, which can backfire badly. They can end up in a situation where they think they’ve fixed a security hole but break other code in the process and get even more headaches.
• Bridge between network and security:
  ZTNA sits at that boundary; we translate goals into workable designs both sides can trust. It’s worth mentioning we use the same services ourselves in our company that our customers use, so we really experience how they work and what the issues are.

A couple of stories from the field

What I appreciate is the experience I gain from dealing with various issues in each project, which I can then pass on to customers in future projects. Over the years, some memorable stories spring to my mind.

80 sites in six months – and a keg

During a fast-paced migration for an innovative, global manufacturer, somewhere along the way we helped untangle network issues that weren’t directly related to the migration. The customer’s team kept joking, “We owe you a beer.”

Two years later, they showed up with a barrel! That’s the kind of partnership we aim for.

M&A without mayhem

I find that managed ZTNA shines in cross-company changes, like the time when one of our customers was acquired by a large international enterprise. There, we used ZTNA to standardize internal resource access quickly while keeping the production environments of both merged companies running.

Want a fast start?

If you’re beginning your Zero Trust journey, our guidance is simple: secure third-party access first, retire broad VPN access, and grow ZTNA policy depth from there – with consistent policy enforcement and one set of rules for everyone, everywhere. It’s a pragmatic path that delivers value early and compounds over time.

If you’d like a deeper dive into the ZTNA phases and how we run projects so smoothly that customers barely notice the change – that’s our managed ZTNA service by design. And it’s how we measure success.

Do you have questions or a use case to test? Tell us the outcome you want. We’ll make it work and keep it working.