COSGrid MicroZAccess is an agent-based Zero Trust Network Access (ZTNA) solution built around a peer-to-peer Mesh ZTNA architecture. Instead of treating network connectivity as proof of trust, MicroZAccess evaluates whether a specific identity, using a specific device, under applicable security conditions, should be allowed to access a specific application or resource.

The core principle is simple: connectivity is not authorization. A user being connected to an access environment does not automatically grant access to the surrounding network. MicroZAccess applies identity-driven, application-specific access so users receive only the resources explicitly permitted by policy.

MicroZAccess separates centralized access management from the application data path. Policies and access controls are managed centrally, while authorized application traffic uses a direct encrypted connection between the authorized endpoint and the protected resource. This supports least-privilege access, application-level segmentation, and reduced unnecessary network exposure.

02 — MESH ZTNA FUNDAMENTALS

What is Mesh ZTNA?

Mesh ZTNA is an approach to Zero Trust Network Access in which authorized endpoints and protected resources can communicate directly over an encrypted peer-to-peer access fabric. Instead of placing a centralized traffic broker in the path of every application session, MicroZAccess uses centralized control to determine whether a connection is permitted and then establishes direct connectivity between authorized participants.

This distinction matters because the control plane governs identity, policy, device trust, and access decisions; it is not the mandatory path for application traffic. Once authorization is satisfied, the application session follows the direct authorized connection.

03 — ZERO TRUST PRINCIPLES

The Core Idea: Connectivity is not authorization

Traditional remote-access models commonly begin by establishing network connectivity. After a user connects, the reachable network can become the practical trust boundary. MicroZAccess starts with the application instead: should this identity, on this device, under these conditions, be allowed to access this particular resource?

04 — ARCHITECTURE AND COMPONENTS

MicroZAccess Architecture

MicroZAccess combines identity, endpoint trust, centralized policy management, and direct application connectivity. Its main public-facing components are described below.

Access input

User

Identity

Device

Security context

Policy

Protected application

Access decision

Role in the decision

Identifies the person requesting access.

Provides authenticated identity and relevant group or role information.

Identifies the endpoint from which access is requested.

Provides applicable device posture and contextual conditions.

Defines who can access which resources and under what conditions.

Defines the exact resource being requested.

Determines whether the requested access is allowed or denied.

User

The user initiates access to a protected application. Authentication establishes identity, while group or role information can be used for authorization.

COSGrid MicroZ Client

The endpoint client enables the device to participate in Zero Trust access and provides device and security-context information used during policy evaluation and enforcement.

Identity Provider (IdP)

The organization's IdP establishes the user's identity. Enterprise authentication, SSO, MFA, and group or role information can become inputs to application access policy.

COSGrid Guider

COSGrid Guider provides centralized management and control functions for policies, access configuration, identity and device lifecycle functions, and access visibility.

Trust Broker

The Trust Broker supports control and coordination required to establish authorized peer relationships. It is not the mandatory application traffic path.

COSGrid App Connector

COSGrid Guider provides centralized management and control functions for policies, access configuration, identity and device lifecycle functions, and access visibility.

Protected Application

The business resource being accessed. Policy scopes access to the application or resource rather than automatically granting access to the surrounding network.

05 — ACCESS REQUEST WORKFLOW

How a MicroZAccess access request works?

1. User initiates access

The user requests an internal application or protected resource.

2. Device is verified

The requesting endpoint is identified and its enrollment or trust state is considered.

3. Security context is evaluated

Applicable device posture and contextual conditions are evaluated against policy requirements.

4. Policy is evaluated

Identity, group or role, device, context, requested application, and policy conditions are evaluated together.

5. Access is authorized or denied

Only requests satisfying applicable policy are allowed.

6. Direct secure connection is established

When permitted, an encrypted direct connection is established between the authorized endpoint and the protected application or access point.

7. Enforcement continues

Changes in identity, device state, context, or policy can affect continued access.

How a MicroZAccess access request works?

06 — IDENTITY AND AUTHENTICATION

Identity Verification and Authentication

Identity is a fundamental input to Zero Trust access. MicroZAccess uses authenticated identity rather than network location as the primary basis for determining who is requesting an application. Organizations can use their existing Identity Provider and authentication controls.

Enterprise identity integration

Single sign-on and configured MFA controls

Group- and role-based authorization

Alignment with existing identity lifecycle and governance

07 — DEVICE TRUST AND CONTEXT-AWARE ACCESS

Device Trust and Security Context

User identity alone is not sufficient for Zero Trust access. MicroZAccess can incorporate device trust, security posture, and contextual information into access decisions. Exact signals depend on organizational configuration.

Signal / context

Device identity

Endpoint security

Operating system

Network context

Location context

Time context

Requested application

Example consideration

Is the endpoint known and enrolled?

Are required security controls active?

Does the device meet the configured OS condition?

Does the request satisfy the configured network requirement?

Does the request satisfy configured location requirements?

Is access occurring within the permitted time window?

Is this identity or group authorized for this resource?

These signals can be combined differently for different applications. A sensitive application can require stronger device and contextual conditions than a lower-risk application.

08 — POLICY AND LEAST-PRIVILEGE ACCESS

Policy Evaluation and Least-Privilege Access

Policy converts Zero Trust principles into enforceable access controls. A MicroZAccess policy defines who can access a resource and the conditions that must be satisfied.

Policy element

Subject

Resource

Device requirements

Context

Effect

Purpose

User, group, role, or identity to which the rule applies.

Specific application or protected resource.

Applicable endpoint trust or posture conditions.

Network, location, time, or other configured conditions.

Determines whether the request is permitted.

MicroZAccess follows a least-privilege approach: access is explicitly permitted rather than assumed from network membership. A user permitted to access one application does not automatically receive access to other applications simply because they share the same environment.

09 — APPLICATION ACCESS AND MICROSEGMENTATION

Application-Level Access and Zero Trust Microsegmentation

Microsegmentation limits unnecessary communication between identities, devices, applications, and resources. MicroZAccess makes the protected application the practical unit of access control, allowing organizations to define access around business resources rather than granting a broad network position.

Traditional network access

Grants a position on a network

Network can become a broad trust boundary

Unrelated resources may be reachable

Segmentation can require network changes

Compromise can create broad reachability

MicroZAccess application access

Grants access to specific authorized applications

Each application is an explicit access boundary

Unrelated applications remain outside permitted scope

Access segmentation is expressed through policy

Least privilege limits available resources

Application-Level Access and Zero Trust Microsegmentation

10 — CONTINUOUS ENFORCEMENT

Continuous Zero Trust Enforcement

Zero Trust is not simply a login event. The conditions that justified access can change after authentication. MicroZAccess is designed to keep access aligned with applicable identity, device, context, and policy conditions.

A user's group or role can change.

A device can move out of compliance.

Device security posture can change.

An administrator can modify or revoke policy.

Network, location, or time context can change

Access can be withdrawn when required conditions are no longer satisfied.

11 — VPN VS ZERO TRUST ACCESS

MicroZAccess vs VPN: What is the difference?

The key difference is the access boundary. A traditional VPN commonly provides network-level connectivity after authentication. MicroZAccess focuses on application-specific connectivity governed by Zero Trust policy.

VPN / traditional remote access

Network-level connectivity

Potentially broad network reachability

Network can become a trust boundary

Greater potential for unnecessary reachability

Remote network access model

MicroZAccess ZTNA

Application-specific connectivity

Only policy-permitted resource access

Identity, device, context, and policy form the access boundary

Least privilege limits unnecessary access

Secure application access model

MicroZAccess can serve as a Zero Trust alternative to broad VPN access or be introduced alongside existing remote-access technologies during migration.

12 — DIRECT SECURE CONNECTIVITY

Direct Application Connectivity

After authorization, MicroZAccess establishes a direct encrypted connection between the authorized endpoint and the protected application or appropriate application access point. COSGrid Guider manages and governs access; it is not the mandatory path for application traffic.

This separation keeps application communication focused on the resource that policy permitted. Authorization to one application does not imply authorization to neighboring resources.

13 — ACCESS DENIAL AND DEFAULT-DENY BEHAVIOR

What happens, when access is denied?

The user requests a protected application.

The request is evaluated against identity, device, context, and policy.

If required conditions are not satisfied, access is denied.

No authorized application connection is established.

The event can be recorded for visibility, investigation, and auditing.

Default-deny behavior means that an unauthorized resource does not need a separate rule for every user. If access has not been explicitly permitted, it remains outside the user's authorized application scope.

14 — CONTROL PLANE AND DATA PATH

Control Plane and Application Data Path

Control / management functions

Identity and device lifecycle

Policy authoring and management

Policy distribution

Access visibility and reporting

Application data path

Authorized application traffic

Communication with permitted resources

Protected application data

Application session traffic

Centralized management governs access, while authorized application traffic follows the direct connection established for the permitted resource.

15 — MONITORING AND VISIBILITY

Monitoring and Visibility

Visibility helps security teams understand how Zero Trust policies operate and investigate access outcomes.

Authentication activity Application access activity Allow and deny decisions Device and endpoint status Security and posture-related events Access history for investigation and auditing

A useful access record should help answer: Who requested access? Which application was requested? When did it happen? Was access allowed or denied? Which policy or condition affected the decision?

16 — USE CASES

Common MicroZAccess Use Cases

Secure remote workforce access

Identity-driven access to internal applications without treating remote connectivity as broad network trust.

VPN replacement or augmentation

Introduce application-specific Zero Trust access while reducing dependence on broad network-level remote access.

Application-level microsegmentation

Limit users and devices to the applications and resources required for their roles.

Workload and infrastructure access

Protect selected workloads and internal services across distributed environments.

Enterprise and cloud environments

Apply consistent identity and application access principles across on-premises and cloud resources.

Third-party and contractor access

Provide scoped access to required applications while reducing unnecessary exposure to other resources.

17 — USER JOURNEY

Example User Journey

Consider a finance employee who needs a loan-processing application and an internal analytics platform but does not need engineering or HR systems.

The employee signs in through the organization's IdP and completes configured authentication.

MicroZAccess verifies identity and relevant group or role information.

The endpoint's trust and applicable security context are evaluated.

Policy checks whether the user and device satisfy requirements for each requested application.

Access is granted only to explicitly permitted applications.

Unrelated applications remain outside the authorized access scope.

If identity, device state, context, or policy changes, access can be reevaluated and adjusted.

18 — SECURITY PRINCIPLES

Security Principles behind MicroZAccess

Verify identity: Use authenticated identity as a primary access signal.

Verify the device: Consider the trust and security state of the requesting endpoint.

Apply least privilege: Grant only the application access required for the user's role.

Do not trust network location alone: A corporate network connection should not automatically imply application access.

Make the application the access boundary: Control access to specific resources instead of granting broad network reachability.

Continuously enforce: Keep access aligned with changing identity, device, context, and policy conditions.

Default to deny: Access that is not explicitly permitted should not be available.

Maintain visibility: Record access activity and decisions so security teams can investigate and audit them.

19 — FREQUENTLY ASKED QUESTIONS

Frequently Asked Questions about MicroZAccess

What is MicroZAccess?

COSGrid MicroZAccess is an agent-based Zero Trust Network Access solution that provides identity-driven, application-specific access using user identity, device trust, security context, and policy.

How does MicroZAccess work?

MicroZAccess verifies identity, evaluates the requesting device and applicable context, checks policy for the requested application, and establishes access only when the required conditions are satisfied.

How is MicroZAccess different from a VPN?

A traditional VPN commonly provides network-level connectivity after authentication. MicroZAccess focuses on application-level access so users receive only resources permitted by Zero Trust policy.

Does MicroZAccess support application-level access?

Yes. Application-specific access is a core part of the MicroZAccess Zero Trust model.

What is Zero Trust microsegmentation?

Zero Trust microsegmentation limits access between identities, devices, applications, and resources so users receive only the connectivity required for their role.

Does MicroZAccess use device posture?

MicroZAccess can use device trust and security posture as inputs to access policy, allowing organizations to consider endpoint security state when granting application access.

Does MicroZAccess support MFA?

MicroZAccess can use multi-factor authentication through the organization's configured identity and authentication controls.

Can MicroZAccess replace a VPN?

MicroZAccess can be used as a Zero Trust alternative to broad VPN-based application access or alongside existing remote-access technologies during migration.

Why is least-privilege access important?

Least privilege reduces unnecessary reachability. If an identity is compromised, limiting access to required applications can reduce the potential scope of unauthorized activity.

What happens when a user is not authorized?

The requested access is denied and no authorized connection to the protected resource is established. Access activity can also be recorded for visibility and investigation.

20 — KEY TAKEAWAYS

Key Takeaways

Connectivity is not authorization. Joining the access environment does not automatically provide application access.

Identity, device, security context, policy, and the requested application can be considered together when determining access.

MicroZAccess applies least-privilege, application-specific access rather than broad network access.

Application-level access supports Zero Trust microsegmentation and helps reduce unnecessary lateral movement

Device trust and security posture can strengthen access decisions beyond user authentication alone.

Continuous enforcement helps keep access aligned with changing identity, device, context, and policy conditions.

Authorized application traffic uses a direct encrypted connection rather than a mandatory centralized traffic path.

Centralized policy management and distributed enforcement provide a scalable way to govern application access.