Agent-Based Zero Trust Network Access Use Cases

Give every user access to only the private applications, servers, databases, and services their role requires. See how enterprises apply least-privilege access across infrastructure, applications, and endpoints.

Learn More Book a Demo

PROBLEM STATEMENT

What is Agent-Based ZTNA?

Software on the device grants access to specific private resources, not the whole network.
Each request is checked against policy.

Traditional VPN / flat network

Trusts the connection once established
Reaches more systems than the job needs
Easy lateral movement
Hard to audit

With MicroZAccess

Every request checked against policy
Only the resources the role requires
Servers, databases, apps, APIs, engineering envs

Infrastructure and Servers

Secure Access to Windows Servers

Give IT administrators access to the Windows servers they manage, and no others.

Administrators often need to manage Windows servers across data centres and private clouds. Remote administration services that are broadly reachable create unnecessary exposure. MicroZAccess lets you define which administrators can reach which Windows servers, so access follows operational need rather than network location.

Example policy: Windows infrastructure administrators reach production domain controllers. Support technicians reach only the file servers in their region.

Secure Access to Linux Servers

Restrict engineers to the Linux hosts they operate.

Linux servers host core business workloads, and direct network access to them can expose far more than an engineer needs. MicroZAccess restricts connectivity to designated hosts for approved users, reducing the exposure of administrative services across your fleet.

Example policy: Platform engineers reach production application hosts. Developers reach staging hosts only.

Secure Access to Kubernetes Clusters

Control who can reach cluster control planes and the workloads running on them.

Kubernetes clusters run production workloads and expose powerful administrative interfaces. MicroZAccess restricts access to designated clusters so that only approved engineers reach the control plane. Protocol-specific behaviour, including kubectl operations, gRPC, WebSockets, and long-lived sessions, is confirmed for each deployment during onboarding.

Example policy: SRE team members reach production clusters through approved sessions. Application developers reach development clusters only.

Protecting CI/CD and Deployment Infrastructure

Limit access to build servers, artifact repositories, and deployment targets.

CI/CD pipelines hold credentials and can push code to production, which makes them high-value targets. MicroZAccess restricts access to these systems to the people and services that operate them. A compromised workstation then cannot reach deployment infrastructure it has no reason to touch.

Example policy: Release engineers reach the deployment controller. Developers can view build logs but cannot reach production deployment targets.

Databases and Data

Secure Access to PostgreSQL Databases

Restrict database connectivity to the people and environments that need it.

Production PostgreSQL databases hold customer and operational data. Broad network access lets many more users reach them than need to. MicroZAccess restricts connectivity to approved database instances, so developers reach the environments they work in without exposure to the wider database network.

Example policy: Backend developers reach staging databases. Only the DBA group reaches production.

Secure Access to Microsoft SQL Server

Give reporting and application teams access to their own databases only.

Microsoft SQL Server instances often back finance, reporting, and line-of-business applications, and each group needs different access. MicroZAccess enforces separate policies so reporting users reach reporting databases and application teams reach their own systems.

Example policy: BI analysts reach the reporting data marts. The finance application team reaches only its own SQL Server instance.

Securing Data Engineering Pipelines

Limit each engineer and service account to the data stores their pipelines need.

Data pipelines connect many sources and destinations, and engineers often hold broad access to all of them. MicroZAccess limits each engineer or service account to the specific data stores and tools they use. This reduces the impact of a credential leak.

Example policy: Ingestion engineers reach the raw data landing zone. Analysts reach curated warehouse schemas only.

Applications and APIs

Secure Access to Internal APIs and Microservices

Limit each team to the internal services it owns.

Microservice architectures expose many internal endpoints, and not every engineer needs to call every one. MicroZAccess limits access to specific internal APIs according to user and service. This helps prevent lateral movement between services that should stay isolated.

Example policy: The payments team reaches the payments API. The reporting team reaches read-only endpoints for reporting services.

Separating Development, Staging, and Production Access

Keep production isolated from everyday developer access.

Development, testing, and production environments often share a network, so a developer’s laptop can reach production systems by default. MicroZAccess applies policies by environment, so production connectivity is limited to a small, approved group.

Example policy: All engineers reach development and staging. Production access requires membership in the on-call group.

Finance and ERP System Access

Enforce role-based access to payroll, ledger, and procurement modules.

Finance and ERP systems hold payroll, ledger, and procurement data that must be restricted by role. MicroZAccess enforces role-based connectivity, so users reach only the financial modules and environments their responsibilities require.

Example policy: Accounts payable staff reach the procurement module. Payroll administrators reach the payroll environment. Neither group reaches the other’s system.

Remote employee application access use case

Workforce, Endpoints, and Third Parties

Remote Employee Access to Internal Applications

Replace broad remote access with application-level access for distributed teams.

Remote and hybrid employees need reliable access to internal tools. A traditional VPN places them on the corporate network with wide reach. MicroZAccess gives remote staff access only to the applications their role requires, supporting least privilege without the broad connectivity of a full tunnel.

Example policy: HR staff reach the HR system from any location. They cannot reach engineering systems.

Securing Access from Managed Corporate Laptops

Make endpoint status part of the access decision.

Managed corporate devices are the primary way employees reach sensitive systems, so they should be part of the access decision. MicroZAccess supports agent-based access from supported endpoint platforms. Device-security signals can form part of the policy, depending on your product version and configuration.

Example policy: Access to internal engineering resources requires a managed device with the agent installed and running.

Secure Access for Vendors and Contractors

Give third parties access to the named systems they support, and nothing else.

External vendors and contractors often need one or two internal systems, not the whole network. MicroZAccess grants third parties access only to the applications they support, keeping the rest of your infrastructure out of reach. Access can be reviewed and removed when a contract ends.

Example policy: An external ERP support vendor reaches the ERP test environment only, for the duration of its contract.

Offshore and Outsourced Development Team Access

Give distributed teams working access without exposing production.

Outsourced development teams need working access to build and test, but rarely need production systems. MicroZAccess limits these teams to development and staging environments. Production stays isolated while collaboration remains productive.

Example policy: The outsourced team reaches the development and QA environments. Production is excluded from its policy.

Temporary Access for Mergers, Acquisitions, and Integrations

Grant scoped access during integration and remove it when the project ends.

During an acquisition, staff from both organisations often need limited access to each other’s systems for a defined period. MicroZAccess lets you grant access to specific resources during integration and withdraw it when the project closes, without redesigning the network.

Example policy: Integration analysts from the acquired company reach one shared reporting database for the six-month integration programme.

Privileged administrator access use case

Security, Governance, and Compliance

Privileged Administrator Access Without Standing Network Access

Remove always-on administrative exposure.

Privileged administrators are a prime target for attackers, and standing access to admin interfaces increases risk. MicroZAccess restricts administrative connectivity to defined users and resources, so privileged paths are not open to the whole network at all times.

Example policy: Domain administrators reach domain controllers only from managed devices, and only to the specific systems they administer.

Security Operations Tool Access

Restrict SIEM, logging, and monitoring platforms to authorised analysts.

SIEM and logging platforms contain sensitive security telemetry, and access to them should be tightly controlled. MicroZAccess restricts connectivity so that only authorised SOC analysts and security engineers reach these tools.

Example policy: Tier 1 analysts reach the SIEM dashboards. Only detection engineers reach the rule management console.

Access Control for Regulated Industry Systems

Enforce least-privilege access to sensitive systems in healthcare, financial services, and the public sector.

Regulated organisations must show who accessed which sensitive systems. MicroZAccess supports least-privilege policies and centralised access administration. The logging capabilities available in your deployment can support audit and compliance reviews.

Example policy: Clinical staff reach the patient records application. Research staff reach an anonymised data environment only.

Hybrid Cloud and On-Premises Resource Access

Apply one access policy model across data centres and private clouds.

Many enterprises run workloads on-premises and in private clouds at the same time. Managing access separately in each location creates gaps. MicroZAccess supports a single policy model for private resources across these environments, managed through the COSGrid platform.

Example policy: One policy governs a payments application running in a private cloud and its database in an on-premises data centre.

Replacing Legacy Jump Hosts and Bastion Servers

Swap shared intermediaries for individually assigned, policy-controlled access.

Jump hosts and bastion servers are often shared, poorly monitored, and difficult to audit. MicroZAccess replaces many of these administrative paths with individually assigned, policy-controlled access to designated resources.

Example policy: Each administrator reaches assigned servers directly through policy. The shared jump host is retired for those paths.

COMPARISON

Agent-based ZTNA vs. VPN vs. Agentless ZTNA

Factor	Traditional VPN	SwiftZAccess (Agentless ZTNA)	MicroZAccess (Agent-based ZTNA)
Network access granted	Broad, network-level	Application-level, browser-based	Resource-level, per policy
Non-browser protocols (SSH, database clients, kubectl)	Supported	Typically limited	Supported for confirmed protocols
Endpoint software required	Usually	No	Yes
Lateral movement risk	High	Low	Low
Policy granularity	Coarse	Application-level	Per user, resource, and environment

Frequently asked questions

FAQ

What is agent-based ZTNA?

Agent-based Zero Trust Network Access uses software on the user’s device to control access to private applications and resources. Access is granted by configured security policies, not because a user is on the corporate network.

How does MicroZAccess differ from a traditional VPN?

A VPN typically places a connected user on the network with broad reach. MicroZAccess grants access to specific designated resources, which reduces unnecessary connectivity. Whether it can replace a particular VPN depends on the protocols and applications involved.

Can MicroZAccess secure access to PostgreSQL and Microsoft SQL Server?

Yes. PostgreSQL and Microsoft SQL Server are supported in [versions]. Database connectivity is validated during deployment planning. [Link to protocol matrix]