Implementing Zero Trust Network Access: A SkyCore Guide for 2026

Step 1: Understand Zero Trust Principles and Assess Current State

Before any technical implementation, it is crucial to establish a foundational understanding of Zero Trust principles and assess your organization's current security posture against these tenets. Zero Trust, at its core, operates on the principle of "never trust, always verify." This replaces the outdated perimeter-centric model that assumed everything inside the network was safe. Modern attacks leverage identity compromise and phishing, making network location irrelevant to trust. NIST SP 800-207 defines Zero Trust as an evolution of enterprise cybersecurity, while Microsoft emphasizes three core principles:

• Verify Explicitly: Every access request is authenticated and authorized based on all available data points, including user identity, device health, location, service workload, data classification, and anomalies.
• Use Least Privilege Access: Users and workloads are granted only the minimum access needed to perform their tasks, for the shortest time required (Just-In-Time and Just-Enough-Access). This significantly limits the blast radius in the event of a compromise.
• Assume Breach: Design security controls with the expectation that attackers might already be operating within the environment. Focus on limiting impact, enabling rapid detection, and facilitating prompt response.

An initial assessment involves reviewing existing access controls, identity management, device management, application security, and network segmentation against these principles. The CISA Zero Trust Maturity Model provides a useful framework for organizations to evaluate their current state across five pillars: Identity, Devices, Applications & Workloads, Data, and Network, and progress towards higher maturity levels.

# No direct command-line action for this conceptual step.
# Focus on documentation review and internal audit.
Write-Host "Review NIST SP 800-207 and Microsoft Zero Trust Overview for foundational understanding."
Write-Host "Conduct an internal audit of current access controls against Zero Trust principles."

Expected result: A clear understanding of Zero Trust principles and a baseline assessment of your organization's current security maturity level, highlighting areas for improvement.

Step 2: Define ZTNA Business Scenarios and Policy Objectives

Align Zero Trust principles with specific business outcomes by identifying critical access scenarios and defining the security objectives for each, ensuring policies are both effective and practical. This strategic phase ensures that technical implementations serve real-world needs and risks. Consider scenarios like "remote access to SaaS applications," "privileged access to Azure infrastructure," or "contractor access to specific data repositories." For each scenario, define:

• Who: Which users or groups are involved?
• What: Which applications or resources are being accessed?
• Where: From what locations (trusted, untrusted, specific countries)?
• How: What device types (corporate-managed, personal), compliance states, or client applications are used?
• When: Are there time-based constraints or continuous evaluation needs?

For instance, a business scenario might be "Admins accessing production Azure resources." The objective would be "Require MFA and a compliant, privileged access workstation (PAW) for all admin access to Azure management portals."

# This step is primarily strategic and involves business and security team collaboration.
# Document your identified scenarios and objectives for future policy creation.
Write-Host "Initiate workshops with business and IT stakeholders to define critical access scenarios."
Write-Host "Document clear, measurable security objectives for each scenario, mapping them to Zero Trust principles."

Portal alternative: Conduct brainstorming sessions and document outcomes using collaboration tools. This step is about planning, not configuration.

Expected result: A prioritized list of business scenarios, each with clearly defined security objectives, ready to be translated into technical policies.

Step 3: Implement Core Identity-Centric Policies with Conditional Access

Leverage Microsoft Entra Conditional Access as the Zero Trust policy engine to enforce robust identity verification, beginning with Multi-Factor Authentication (MFA) for key user groups and administrative roles. Conditional Access brings together signals like user identity, device, location, and application to make real-time access decisions, enforcing policies after first-factor authentication. Requiring MFA for administrative roles is a fundamental ZTNA step, aligning with "Verify Explicitly."

# Install Azure AD PowerShell module if not already present
# Install-Module -Name AzureAD
# Connect-AzureAD

# Create a Conditional Access policy to require MFA for all administrators.
# Note: Using Azure CLI for creating policies is generally more direct for complex JSON.

# First, get the Object ID for the 'Global Administrator' role (or other admin roles)
$globalAdminRoleId = (Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq 'Global Administrator'}).ObjectId
Write-Host "Global Administrator Role ID: $globalAdminRoleId"

# Define the Conditional Access policy JSON for Azure CLI
$policyJson = @{
    displayName = "Require MFA for Global Administrators"
    state = "Enabled" # Start with 'ReportOnly' in production, then 'Enabled' after testing
    conditions = @{
        users = @{
            includeRoles = @($globalAdminRoleId)
        }
        applications = @{
            includeApplications = @("All") # Target all cloud apps
        }
        clientAppTypes = @(
            "all"
        )
    }
    grantControls = @{
        accessControls = @(
            "Mfa"
        )
        operator = "OR" # In this simple case, 'OR' or 'AND' effectively means "require MFA"
    }
} | ConvertTo-Json -Depth 5

# Save the JSON to a temporary file
$policyJson | Out-File -FilePath C:\temp\MFA_GlobalAdmins_Policy.json -Encoding UTF8

# Execute the Azure CLI command to create the policy
az ad conditional-access policy create `
    --data "@C:\temp\MFA_GlobalAdmins_Policy.json"

Flag explanations:

• --data "@C:\temp\MFA_GlobalAdmins_Policy.json": Specifies the path to a JSON file containing the policy definition.
• displayName: A human-readable name for the policy.
• state: Can be Enabled, Disabled, or ReportOnly. Always start with ReportOnly to monitor impact without enforcing.
• conditions.users.includeRoles: Specifies that this policy applies to users assigned to the listed Microsoft Entra roles.
• conditions.applications.includeApplications: All means the policy applies to all cloud applications.
• conditions.clientAppTypes: Defines the client applications to which the policy applies. all covers browsers, mobile apps, desktop apps, etc.
• grantControls.accessControls: An array of access controls to enforce (e.g., Mfa for Multi-Factor Authentication).
• grantControls.operator: Defines how multiple access controls are combined. OR means any one of the specified controls is sufficient; AND means all must be satisfied.

Portal alternative: Navigate to Microsoft Entra admin center > Identity > Conditional Access > Policies. Click 'New policy', name it, configure 'Users or workload identities' to 'Roles' and select 'Global Administrator'. Under 'Cloud apps or actions', choose 'All cloud apps'. Under 'Grant', select 'Require multifactor authentication' and set to 'On' or 'Report-only'.

Expected result: A Conditional Access policy is created and initially set to ReportOnly. After monitoring, change the state to Enabled to enforce MFA for all targeted administrators, significantly strengthening identity-based access.

Step 4: Enhance Device Posture-Based Access Controls

Integrate device state and compliance as critical signals in your Conditional Access policies to ensure that only healthy and managed devices can access sensitive resources, bolstering your Zero Trust stance. This aligns with the "Verify Explicitly" principle by extending trust verification beyond the user to the device itself. Devices can be marked as compliant by solutions like Microsoft Intune or configured as Microsoft Entra hybrid joined for corporate-managed devices.

# Extend the previous policy or create a new one to require compliant devices for specific applications.
# Example: Require compliant devices for accessing Microsoft 365 services.

# First, get the Object ID for Microsoft 365 Core (or other applications)
# Note: "Microsoft Office 365 (All Applications)" is a common target.
# You might need to find the specific App ID for individual apps if not using "All"
# For simplicity, we will use "All" in this example, but in a real scenario, you'd find the App IDs.

# Define the Conditional Access policy JSON for Azure CLI
$policyJson = @{
    displayName = "Require Compliant Device for Microsoft 365 Access"
    state = "ReportOnly" # Start with 'ReportOnly'
    conditions = @{
        users = @{
            includeUsers = @("All") # Target all users
            excludeUsers = @(
                "Guest" # Exclude guests, if desired
            )
        }
        applications = @{
            includeApplications = @(
                "00000003-0000-0ff1-ce00-000000000000" # Microsoft Graph (common for MS365)
                "00000002-0000-0ff1-ce00-000000000000" # Microsoft Intune
                # Add other specific MS365 App IDs here, or use "All" for all cloud apps
            )
        }
        platforms = @{
            includePlatforms = @(
                "windows"
                "iOS"
                "android"
                "macOS"
            )
        }
        deviceStates = @{
            # includeDeviceStates = @("managed", "compliant") # 'compliant' is often preferred
            includeDeviceStates = @("compliant")
        }
    }
    grantControls = @{
        accessControls = @(
            "CompliantDevice" # Require the device to be marked as compliant
        )
        operator = "AND"
    }
} | ConvertTo-Json -Depth 5

# Save the JSON to a temporary file
$policyJson | Out-File -FilePath C:\temp\CompliantDevice_MS365_Policy.json -Encoding UTF8

# Execute the Azure CLI command to create the policy
az ad conditional-access policy create `
    --data "@C:\temp\CompliantDevice_MS365_Policy.json"

Flag explanations:

• conditions.applications.includeApplications: Specifies the target applications by their Application ID.
• conditions.platforms.includePlatforms: Defines the operating systems the policy applies to.
• conditions.deviceStates.includeDeviceStates: Specifies that the device must meet a certain state, such as compliant (managed by Intune and meets compliance policies).
• grantControls.accessControls: CompliantDevice ensures only devices marked as compliant by your MDM solution are granted access.

Portal alternative: Go to Microsoft Entra admin center > Identity > Conditional Access > Policies. Create a new policy. Under 'Cloud apps or actions', select specific Microsoft 365 apps. Under 'Conditions' > 'Devices' > 'Filter for devices', select 'Include' and choose device platforms. Under 'Grant', select 'Require device to be marked as compliant' and set to 'On' or 'Report-only'.

Expected result: Access to specified applications is now conditional on the user's device being compliant with organizational security policies, significantly reducing risk from unmanaged or unhealthy endpoints.

Step 5: Secure Application Access and Data Flows

Apply granular Conditional Access policies to specific applications and data, ensuring that access is conditioned on explicit verification, appropriate application protection, and session controls. This extends the ZTNA model to the application layer, ensuring that even trusted users on trusted devices interact with data securely, aligning with "Use Least Privilege Access." Policies can require approved client apps, app protection policies (e.g., Intune Mobile Application Management), or integrate with Microsoft Defender for Cloud Apps for real-time session monitoring.

# Example: Require an approved client app and an app protection policy for a specific sensitive SaaS application.
# This assumes the application is registered in Microsoft Entra ID.

# Define the Conditional Access policy JSON for Azure CLI
$policyJson = @{
    displayName = "Require Approved App and App Protection for Sensitive SaaS App"
    state = "ReportOnly" # Always start with 'ReportOnly'
    conditions = @{
        users = @{
            includeUsers = @("All")
        }
        applications = @{
            includeApplications = @(
                "" # Replace with the Application ID of your sensitive SaaS app
            )
        }
        clientAppTypes = @(
            "mobileAppsAndDesktopClients"
        )
        devicePlatforms = @{
            includePlatforms = @(
                "iOS"
                "android"
            )
        }
    }
    grantControls = @{
        accessControls = @(
            "ApprovedClientApp"
            "AppProtectionPolicy"
        )
        operator = "AND" # Both conditions must be met
    }
} | ConvertTo-Json -Depth 5

# Save the JSON to a temporary file
$policyJson | Out-File -FilePath C:\temp\ApprovedAppProtection_SaaS_Policy.json -Encoding UTF8

# Execute the Azure CLI command to create the policy
az ad conditional-access policy create `
    --data "@C:\temp\ApprovedAppProtection_SaaS_Policy.json"

Flag explanations:

• conditions.applications.includeApplications: Target a specific application by its ID.
• conditions.clientAppTypes: Focus on mobile and desktop clients, where app protection policies are most relevant.
• conditions.devicePlatforms: Specifies the mobile platforms to which the policy applies.
• grantControls.accessControls: Includes ApprovedClientApp (requires the user to access via a Microsoft-approved mobile app) and AppProtectionPolicy (requires the app to be protected by Intune MAM policies).
• grantControls.operator = "AND": Both conditions must be met for access to be granted.

Portal alternative: Create a new Conditional Access policy. Under 'Cloud apps or actions', select the specific sensitive SaaS application. Under 'Conditions' > 'Client apps', select 'Mobile apps and desktop clients'. Under 'Grant', choose 'Require approved client app' and 'Require app protection policy'. Set state to 'Report-only' initially.

Expected result: Enhanced protection for sensitive applications, where access is only permitted through managed, secure client applications with enforced data protection policies.

Step 6: Integrate Real-Time Risk Signals for Adaptive Access

Incorporate real-time and calculated risk detections from Microsoft Entra ID Protection to dynamically adjust access requirements, blocking or escalating authentication for risky sign-ins and users. This is a crucial aspect of "continuous verification" in Zero Trust. Entra ID Protection identifies suspicious activities like impossible travel, leaked credentials, or infected devices, feeding these signals into Conditional Access. Policies can then automatically trigger MFA, enforce a password reset, or block access entirely based on the perceived risk level.

# Example: Block access for high-risk sign-ins.
# This policy targets any sign-in that Microsoft Entra ID Protection classifies as 'High' risk.

# Define the Conditional Access policy JSON for Azure CLI
$policyJson = @{
    displayName = "Block High Risk Sign-ins"
    state = "ReportOnly" # Always start with 'ReportOnly'
    conditions = @{
        users = @{
            includeUsers = @("All")
        }
        applications = @{
            includeApplications = @("All")
        }
        clientAppTypes = @(
            "all"
        )
        signInRiskLevels = @(
            "high"
        )
    }
    grantControls = @{
        accessControls = @(
            "Block"
        )
        operator = "OR"
    }
} | ConvertTo-Json -Depth 5

# Save the JSON to a temporary file
$policyJson | Out-File -FilePath C:\temp\BlockHighRiskSignins_Policy.json -Encoding UTF8

# Execute the Azure CLI command to create the policy
az ad conditional-access policy create `
    --data "@C:\temp\BlockHighRiskSignins_Policy.json"

# Example: Require MFA for medium-risk users.
# This policy targets users whose overall user risk (not just sign-in risk) is 'Medium' or 'High'.

# Define the Conditional Access policy JSON for Azure CLI
$policyJson = @{
    displayName = "Require MFA for Medium/High Risk Users"
    state = "ReportOnly" # Always start with 'ReportOnly'
    conditions = @{
        users = @{
            includeUsers = @("All")
        }
        applications = @{
            includeApplications = @("All")
        }
        clientAppTypes = @(
            "all"
        )
        userRiskLevels = @(
            "medium"
            "high"
        )
    }
    grantControls = @{
        accessControls = @(
            "Mfa"
        )
        operator = "OR"
    }
} | ConvertTo-Json -Depth 5

# Save the JSON to a temporary file
$policyJson | Out-File -FilePath C:\temp\MFA_MediumHighRiskUsers_Policy.json -Encoding UTF8

# Execute the Azure CLI command to create the policy
az ad conditional-access policy create `
    --data "@C:\temp\MFA_MediumHighRiskUsers_Policy.json"

Flag explanations:

• conditions.signInRiskLevels: Applies the policy when the real-time sign-in risk is detected at the specified level (e.g., high).
• conditions.userRiskLevels: Applies the policy based on the aggregated user risk level (e.g., medium, high), indicating a compromised account.
• grantControls.accessControls = "Block": Prevents access entirely.
• grantControls.accessControls = "Mfa": Forces a Multi-Factor Authentication challenge.

Portal alternative: Create new Conditional Access policies. Under 'Conditions', select 'Sign-in risk' and/or 'User risk'. Configure the desired risk levels (e.g., 'High'). Under 'Grant' or 'Session', choose 'Block access' or 'Require multifactor authentication'. Set state to 'Report-only' initially.

Expected result: Your ZTNA posture becomes adaptive, automatically responding to detected identity risks by blocking or escalating authentication, thus embodying the "Assume Breach" and "Verify Explicitly" principles.

Step 7: Apply Least Privilege Access Throughout the Environment

Beyond initial access, continuously evaluate and enforce the principle of least privilege, ensuring users and workloads only possess the minimum necessary access for the shortest duration required. This is a foundational pillar of Zero Trust, as emphasized by both Microsoft and NIST SP 800-207. While Conditional Access manages access *to* resources, least privilege also involves managing permissions *within* resources. This includes:

• Role-Based Access Control (RBAC): Granting permissions based on job function, not individual users.
• Just-In-Time (JIT) Access: Providing elevated permissions only when needed and for a limited time. Azure AD Privileged Identity Management (PIM) is a key tool for this.
• Segregation of Duties: Ensuring no single individual has excessive permissions.
• Workload Identity Management: Applying least privilege to non-human identities (e.g., service principals, managed identities).

# While explicit commands for JIT/PIM activation are beyond the direct scope of the provided docs,
# conceptual commands for reviewing existing role assignments are relevant for assessment.

# Review Azure AD role assignments for potential over-privileging
Get-AzureADDirectoryRoleMember -ObjectId $globalAdminRoleId | Select-Object DisplayName, UserPrincipalName
Write-Host "Review output for unnecessary permanent Global Administrator assignments."

# Review custom RBAC roles in Azure for least privilege adherence
# Requires Azure CLI or Azure PowerShell
az role definition list --custom-role-only true --output table
Write-Host "Evaluate custom roles to ensure they grant only necessary permissions."

# Example of a conceptual command for a just-in-time elevation request (PIM)
# This would typically be done via portal or specific PIM cmdlets/APIs, not direct CA.
# New-AzureADMSSPRPIMAccessRequest -RoleDefinitionId '' -RequestedDuration 'PT1H' -Reason 'Troubleshooting'

Flag explanations:

• Get-AzureADDirectoryRoleMember -ObjectId $globalAdminRoleId: Lists all members assigned to the Global Administrator role.
• az role definition list --custom-role-only true: Lists custom Azure RBAC roles.

Portal alternative: For Microsoft Entra roles, navigate to Microsoft Entra admin center > Identity > Roles & admins > Roles > Global Administrator > Assigned roles. For Azure resource roles, go to the resource/subscription > Access control (IAM) > Role assignments. Implement Azure AD PIM for JIT access by configuring eligible assignments for roles.

Expected result: A significant reduction in standing access and overly permissive assignments, with a focus on JIT access and granular RBAC, thereby minimizing the impact of any potential compromise.

Step 8: Monitor, Audit, and Continuously Refine ZTNA Policies

Establish a robust monitoring, logging, and auditing framework to track access decisions, detect anomalies, and regularly review and refine Zero Trust policies to adapt to evolving threats and organizational needs. Zero Trust is an ongoing journey, not a destination. Microsoft highlights "detection and response are built-in" as a key Zero Trust outcome. Continuous monitoring allows for faster threat identification, containment, remediation, and response.

# Utilize Azure AD sign-in logs and audit logs for monitoring Conditional Access policy effectiveness.

# View recent sign-in logs with Conditional Access details (Azure CLI)
az monitor log-analytics query `
    --workspace  `
    --query "SigninLogs | where TimeGenerated > ago(7d) | project TimeGenerated, UserDisplayName, ConditionalAccessPolicies, Status" `
    --output table

# Review Conditional Access policy audit logs for changes (Azure CLI)
az monitor log-analytics query `
    --workspace  `
    --query "AuditLogs | where Category == 'ConditionalAccess' and TimeGenerated > ago(7d) | project TimeGenerated, InitiatedBy, ActivityDisplayName, TargetResources" `
    --output table

# Remember to convert policies from 'ReportOnly' to 'Enabled' after thorough testing.
# For example, to update the state of a policy:
# az ad conditional-access policy update --name "Require MFA for Global Administrators" --state Enabled

Flag explanations:

• az monitor log-analytics query --workspace --query "...": Executes a Kusto Query Language (KQL) query against your Azure Log Analytics workspace.
• SigninLogs: Table containing user sign-in activity.
• ConditionalAccessPolicies: Field within SigninLogs showing which CA policies were evaluated and their outcome.
• AuditLogs: Table containing audit events for Microsoft Entra ID.
• Category == 'ConditionalAccess': Filters audit logs specifically for Conditional Access related events.

Portal alternative: Navigate to Microsoft Entra admin center > Identity > Monitoring & health > Sign-in logs. Filter by 'Conditional Access' status and review policy results. For policy effectiveness, use Microsoft Entra admin center > Identity > Conditional Access > Policies > 'Report-only' tab to see the impact without enforcement. Regularly review all Conditional Access policies to ensure they remain relevant and effective against evolving threats.

Expected result: A continuous feedback loop where policy effectiveness is measured, anomalies are detected, and policies are iteratively refined to maintain and improve the Zero Trust posture. This ensures agility in response to new risks and changes in organizational requirements.