ZTNA for an Australian industrial business — moving remote and third-party access from broad network trust to controlled application access
The business is an industrial equipment and materials handling supplier. For an industrial business, remote access is not just a convenience — it supports users, suppliers, service partners, business systems, Microsoft 365, operational coordination and support pathways. Traditional VPN can provide access, but it can also grant broader network reach than the user or vendor actually needs.
Inlight IT supported the business with Zero Trust Network Access planning and access modernisation as part of a cyber-first managed IT operating model. The outcome was a clearer access model: application-level access where appropriate, reduced reliance on broad network trust, stronger identity-led control and a practical pathway for managed operation after deployment.
- Client
- Australian industrial business
- Industry
- Industrial
- Location
- Industrial operating environment
- Engagement
- Zero Trust Network Access planning, remote access modernisation and managed access support
- Primary requirement
- Move remote and third-party access toward a more controlled access model, reducing broad network-level trust while keeping business access practical and supportable
- Access foundations
- Identity, MFA, device posture and policy checked before access is granted
- Outcome
- A clearer ZTNA pathway with identity readiness, application scope, access policy, legacy constraints, support ownership and migration sequencing considered together
An Australian industrial business — Zero Trust Network Access for an industrial business
Remote and vendor access moved from broad network trust toward controlled application access.
Five workstreams toward controlled application access
Identity readiness, application and access mapping, transition planning, vendor access control and managed ZTNA operation.
Give users and third parties access to the applications they need, not the network they do not.
From which users and vendors need access, to who owns access policy after deployment and what VPN access may need to remain during transition.
From remote access control and vendor boundaries to staged transition and operational support inside the managed IT rhythm.
ZTNA is strongest when it starts with identity readiness, not a platform decision
The business operates in an industrial environment where technology supports users, business systems, supplier communication, remote access and business continuity. Remote access in this context has to be controlled, practical and supportable.
A VPN can be useful, but it often grants network-level access once the user has authenticated. That model can create unnecessary exposure, especially where contractors, vendors, remote users or shared support pathways are involved.
ZTNA changes the access model: users and third parties access only the applications they are authorised to use, with identity, MFA, device posture and policy checked before access is granted. Inlight IT's role was to help the business approach ZTNA as an access architecture decision, not a simple VPN replacement.
The business needed remote access control that matched an industrial operating environment, not a generic VPN model
Industrial businesses often rely on a mix of remote users, vendor support, supplier systems, business applications, Microsoft 365 and legacy access requirements. The access model needs to support legitimate work without leaving broad network paths open longer than required.
Remote access needed tighter scope
Traditional VPN access can give users or third parties reach into broader network segments. That may be convenient, but it is rarely the least-privilege model. The business needed an access approach where users and support partners could be scoped to the systems they actually required.
Third-party access needed better boundaries
Industrial environments often depend on external vendors and support partners. Those access pathways need to be controlled, reviewed and tied to business need. ZTNA can restrict access to named applications rather than opening broader network access.
Identity readiness had to come before ZTNA deployment
ZTNA depends on a clean identity foundation. Enforced MFA, accurate user groups, device registration, account hygiene and privileged access controls need to be reviewed before access policy is moved into a ZTNA model. Without that work, ZTNA can become a more expensive version of the same trust problem.
Application dependencies needed mapping
Not every application is a natural ZTNA candidate. Cloud apps, web apps and modern applications are generally easier to broker; legacy applications, non-standard protocols and older authentication models may need connectors, exceptions or retained VPN access. The application estate needed to be understood before any migration decision.
The operating model after deployment mattered
ZTNA is not set-and-forget. Access policy, group membership, connector availability, MFA exceptions, device compliance and break-glass access need ongoing ownership. The access model needed to be supportable inside managed IT, not left as a disconnected security project.
ZTNA planning and access modernisation connected to identity, applications and managed operation
Inlight IT supported the business by treating ZTNA as part of the managed IT and cyber-first operating model. The work focused on readiness, access scope, migration planning, policy control and supportability.
01Identity readiness assessment
Checking the access foundation before changing the access model. ZTNA depends on identity quality, so the identity and access foundation was reviewed so policy could be built on accurate users, groups, MFA and device posture.
02Application and access mapping
Understanding which systems needed remote or third-party access, and framing access around application requirements rather than network reach.
03ZTNA and VPN transition planning
Moving progressively rather than forcing a risky cutover — a staged approach so access could be validated before old access pathways were reduced.
04Third-party access control
Reducing broad network access for external parties — vendors scoped to named applications rather than given broader network-level access.
05Managed ZTNA operation
Keeping access policy supportable after deployment, with policy, group membership, connector health, user changes and escalation brought into the managed service rhythm.
From identity readiness to managed access operation
Select a stage to trace how access moved from broad network trust to controlled application access.
The difference between ZTNA and VPN is not encryption. It is trust scope
VPN gives a user network-level access after authentication. ZTNA gives a user access to a named application, based on identity, device posture and policy. Compromised credentials under VPN can expose broader network paths, while ZTNA limits access to the applications explicitly permitted. VPN, remote access, vendor access and identity controls are now part of cyber insurance, Essential Eight, recovery resilience and operational risk conversations.
Five planning workstreams, from identity readiness to managed ZTNA operation.
Eight practical questions answered before any platform commitment, from application brokering to retained VPN access.
One access principle: access to the applications they need, not the network they do not.
Six shifts in the access model, from remote access control to operational support.
The business gained a clearer access model for remote users, third parties and support pathways
The engagement helped the business move toward a more controlled access posture. Instead of treating remote access as broad network connectivity, the access model could be shaped around identity, applications, MFA, device posture, vendor needs and ongoing support.
Remote access control
Remote access could be considered through named users, named applications and access policy rather than broad network reach.
Third-party access
Third-party and support access could be reviewed by business need, identity, application scope and expiry requirements.
Identity foundation
MFA, user groups, device posture and account hygiene were treated as prerequisites for ZTNA, not afterthoughts.
Application clarity
Applications could be assessed for ZTNA suitability, connector requirements, retained VPN needs and migration complexity.
Staged transition
VPN did not need to be removed in one cutover. Legacy applications and user groups could be managed through a staged transition.
Operational support
Access policy, group membership, connector availability, escalation and review could sit inside the managed IT rhythm.
Give users and third parties access to the applications they need, not the network they do not — that is the difference between remote connectivity and controlled access.
ZTNA delivered as access architecture, not a product rollout
Identity readiness before rollout
Identity, MFA, user groups and device posture considered before access changes.
Applications mapped by need
Applications and access pathways reviewed before ZTNA migration sequencing.
Third-party access scope considered
Third-party access considered through named access and least privilege.
Microsoft 365 access aligned
Microsoft 365 and identity dependencies considered as part of access modernisation.
VPN and ZTNA hybrid transition
VPN and ZTNA coexistence considered where legacy applications or staged migration required it.
Managed ongoing ownership
Access policy, escalation, connectors and review considered after deployment.
The work connected identity readiness, access mapping and managed access support
Identity readiness
6- Entra ID & identity readiness
- MFA coverage review
- Device posture considerations
- User and group hygiene
- Privileged access review
- Stale account risk
Access mapping
6- Application access mapping
- Remote access use-case review
- Third-party access review
- Microsoft 365 access alignment
- Legacy application exception planning
- Access group mapping
Transition planning
7- Zero Trust Network Access planning
- ZTNA readiness review
- VPN transition planning
- Pilot user group planning
- Connector & gateway considerations
- Migration sequencing
- Validation before change
Managed access operation
6- Access policy management
- Managed access support
- Group membership review
- Break-glass access considerations
- Access expiry and review
- Security-related escalation
Is your VPN giving users or vendors more access than they need?
We review your access model and where ZTNA fits before you commit to a platform.
Discuss SASE & Zero Trust