How to Operationalize Zero Trust Security

Zero Trust is a security model built on the principle of “never trust, always verify”, which assumes that breaches are inevitable. Therefore, every access request must be verified. While it’s a powerful security model, poor execution can create unnecessary friction for users. The goal is to build conditional, context-aware protections that work quietly in the background while giving admins full control and insight.

This guide outlines methods to operationalize Zero Trust Security for stronger oversight and control.

Methods to operationalize Zero Trust security

Before starting, ensure the following are in place.

📌 General prerequisites:

• Microsoft Entra ID (formerly Azure AD) Premium P1 or P2 (P1 required for Conditional Access; P2 for Identity Protection)
• Microsoft Defender for Endpoint (for device risk assessment)
• PowerShell 5.1+ (7+ recommended) with Microsoft.Graph module
• GPO and local admin access
• RMM platform (e.g., NinjaOne) for tag-based policy deployment and endpoint validation

Method 1 (Identity controls): Build context-based Conditional Access policies

Conditional Access (CA) is the core engine of Zero Trust. It’s a key feature in Microsoft Entra ID that applies rules (grant, restrict, block) based on signals like risk level, device compliance, location, and more. This method helps you build the first line of defense in your Zero Trust strategy.

📌 Use Cases: Best when you need to block access from risky or unmanaged devices and allow seamless access from trusted, compliant endpoints.

📌 Prerequisites:

• Microsoft Entra ID P1 or P2 license (for Conditional Access and Identity Protection)
• Devices registered/synced into Entra ID
• Admin access to the Microsoft Entra admin center
• Optional: PowerShell 5.1+ (7+ recommended) with Microsoft.Graph module for automation/reporting

Step-by-step:

1. Navigate to the Microsoft Entra Admin Center.
2. Sign in using an account with Conditional Access admin rights.
3. In the left-hand menu, select Entra ID > Conditional Access.
4. Click + Create New policy.
5. Give it a clear and descriptive name.
6. Under Assignments, select users/groups to include.
7. Click Target resources (formerly Cloud apps) and select the applications or resources you want the policy to apply to.
8. Click Conditions and set context signals.

💡 Tip: Avoid broad rules that block everyone. Instead, use the available Conditions options (Device platforms, Locations, Client apps, Device filters, or Authentication flows) to apply controls only when specific risks are detected.

9. Grant or block Access controls.
10. Set to Report-only > Create > validate in Insights & reporting > then switch to On. (Read #1 in ⚠️ Things to look out for.)

Optional: Use PowerShell to retrieve risky users

If you want to identify risky users, use PowerShell:

Connect-MgGraph -Scopes “IdentityRiskEvent.Read.All”

Get-MgRiskyUser | Where-Object { $_.RiskLevel -eq “high” } | Select-Object UserPrincipalName, RiskLevel

📌 Note: This command only retrieves users flagged as high risk. You can adjust the filter to include medium or low risk levels if needed.

Sample Conditional Access policy logic

• Block access for unknown devices with risk level = High.
• Require MFA only when accessing from unmanaged or untrusted IPs.
• Allow seamless access from compliant, hybrid-joined, known devices.

Method 2 (Identity controls): Streamline MFA, SSO, and Session Controls

This method strengthens identity security by streamlining MFA, SSO, and session controls to reduce friction without weakening protection. It brings the right balance to a Zero Trust approach.

📌 Use Cases: Use to require MFA for sensitive apps, enable SSO, tune session lifetimes, and improve the overall experience on trusted devices.

📌 Prerequisites:

• Microsoft Entra ID P1 or P2 license (for Conditional Access and adaptive risk)
• Devices registered/synced into Entra ID
• Admin access to the Microsoft Entra admin center
• Optional: PowerShell 5.1+ (7+ recommended) with Microsoft.Graph module for automation

Step-by-step:

Avoid friction by aligning authentication with adaptive access and device trust:

1. Create a Conditional Access policy that requires MFA under Access Controls

1. Navigate to the Microsoft Entra Admin Center.
2. In the left-hand menu, select Entra ID > Conditional Access.
3. Create or edit a policy.
4. Under Access controls, choose Grant Access.
5. Select Require multi-factor authentication.

2. Enable Single Sign-On (SSO)

1. Navigate to the Microsoft Entra Admin Center > Enterprise Applications.
2. Select the application.
3. Under Single Sign-On, choose SAML or OIDC based on the app.
4. Configure app settings.
5. Assign users/groups to the app.
6. Test the configuration to ensure seamless login.

📌 Note: OIDC/OAuth2 is often configured via App registrations (or gallery apps that support OIDC), not only via Enterprise Applications.

3. Configure Session Controls

1. In the same Conditional Access policy, navigate to Session controls.
2. Configure: (Read #2 in ⚠️ Things to look out for.)
   • Sign-in frequency
   • Persistent browser session

Configuring session lifetimes helps balance security and usability.

Optional Registry: Store user/device MFA acknowledgement

📌 Note: Run PowerShell as an Administrator.

Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\TrustFlags” -Name “MFAApproved” -Value “True”

📌 If the registry path doesn’t exist, use the following command to create it before setting the property:

New-Item -Path “HKLM:\SOFTWARE\Org” -Name “TrustFlags” -Force

Pair this with Conditional Access filters to limit MFA prompts to non-tagged or unmanaged devices.

Method 3 (Device baseline): Use GPO to enforce device baseline without user disruption

Group Policy Objects (GPOs) are a reliable solution for centrally managing device configurations. This method uses GPOs to establish a local Zero Trust baseline across Windows endpoints, preventing configuration drift and closing device-level policy gaps.

📌 Use Cases: Ensure all domain-joined devices meet minimum baseline security standards.

📌 Prerequisites:

• Devices must be domain-joined or hybrid-joined
• Domain Admin privileges to create/edit GPOs

Step-by-step:

1. Press Win + R, type gpmc.msc, and click Enter to open the Group Policy Management Console.
2. Right-click your domain or an Organizational Unit (OU).
3. Select Create a GPO in this domain, and Link it here. (Read #3 in ⚠️ Things to look out for.)
4. Give it a name.
5. Right-click the new GPO and click Edit.
6. GPO settings to configure:

• Enable Microsoft Defender Antivirus

Computer Configuration > Policies > Administrative Templates > Windows Components > Microsoft Defender Antivirus 

📌 Set Turn off Microsoft Defender Antivirus to Disabled (this ensures Defender is enabled).

• Enable SmartScreen

Computer Configuration > Administrative Templates > Windows Components > File Explorer

📌 Set Configure Windows Defender SmartScreen to Enabled, and select Warn and prevent bypass.

• Require BitLocker encryption

Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption 

•  Enable the relevant policies for:
  • Fixed Data Drives: Require BitLocker
  • Operating System Drives: Require BitLocker
  • Removable Data Drives: Require BitLocker

• Disable anonymous shares

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

📌 Not applicable for modern Windows Server editions, replaced by stricter defaults.

• Force Secure Desktop for elevation prompts

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

📌 Locate User Account Control: Switch to the secure desktop when prompting for elevation and set it to Enabled.

Optional: Force GPO update

To apply the policy immediately on a client device, run: gpupdate /force

Method 4 (Device Trust & Enforcement): Tag devices via Registry for Trust State management

In Zero Trust environments, registry-based tagging lets you define and track a device’s trust state locally. This method uses registry entries to support script logic, auditing, and policy mapping.

📌 Use Cases: Best for tagging devices as trusted/managed for Conditional Access filtering, letting your RMM scan and assign policies based on flags, and enabling script-based automation.

📌 Prerequisites:

• Admin privileges to modify the registry
• RMM or endpoint management tool (optional but recommended)
• PowerShell or CMD access for scripting and validation

Step-by-step:

1. Open PowerShell as Administrator.
2. Create Registry path for Trust Flags: New-Item -Path “HKLM:\SOFTWARE\Org\TrustFlags” -Force
3. Set Trust Flags: (Read #4 in ⚠️ Things to look out for.)

Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\TrustFlags” -Name “DeviceTrusted” -Value “True”
Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\TrustFlags” -Name “ManagedByRMM” -Value “NinjaOne”

4. Validate Registry keys:
   • Open the Command Prompt and run: reg query HKLM\SOFTWARE\Org\TrustFlags

You should see output like:

HKEY_LOCAL_MACHINE\SOFTWARE\Org\TrustFlags
DeviceTrusted REG_SZ True
ManagedByRMM REG_SZ NinjaOne

Use RMM to scan for these tags and assign scripts or policies accordingly.

📌 Note: Conditional Access can’t directly read registry values. Use Intune custom compliance to map the registry flag > device compliance > Conditional Access to integrate with CA.

📌 Note for NinjaOne users: In Windows environments without an RMM, registry tagging can be used to mark trusted devices. If you’re using NinjaOne, this step isn’t needed. NinjaOne already includes device tagging, registry monitoring, and policy assignment, so trust states are applied automatically without manual registry edits.

Method 5 (Device Trust & Enforcement): Apply PowerShell to enforce local policies in real-time

This method uses PowerShell to enforce security policies instantly on Windows devices without the latency associated with GPOs. It detects noncompliant settings, remediates them in real time, and signals the status to your RMM or CI for alerts.

📌 Use Cases: Best for applying security settings during onboarding and running on-demand compliance checks and remediation scripts.

📌 Prerequisites:

• PowerShell 5.1 or newer
• Admin privileges to run system-level commands
• Optional: RMM or endpoint management tool for remote execution

Step-by-step:

1. Open PowerShell as Administrator.
2. Enable Windows Firewall:

Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True

3. Disable SMBv1 (legacy protocol):

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

4. Audit last login per user:

Get-LocalUser | ForEach-Object {
[PSCustomObject]@{
 User = $_.Name
LastLogon = $_.LastLogon
}
}

5. Integrate these checks into onboarding or compliance scripts.

⚠️ Things to look out for

Additional considerations

Consider the following factors when operationalizing Zero Trust security:

Avoid blocking known good behavior

Conditional Access (CA) policies apply to all accounts unless exceptions are defined. Without proper exceptions, critical workflows may break. For example, service accounts often don’t support MFA and will fail if included. Likewise, secure IPs may not need repeated authentication challenges.

Add service accounts, secure IPs, and business-critical apps to your exception logic to avoid disruptions. This approach preserves strong Zero Trust controls without interfering with day-to-day operations.

Monitor failed sign-ins and policy blocks

Zero Trust requires ongoing monitoring. Use Microsoft 365 sign-in logs and Graph API queries to review authentication trends, track how policies affect users, and identify where risks are emerging. This provides the data you need to refine access rules and adjust enforcement levels.

Train end-users on secure self-remediation

Employees are the front line of your Zero Trust strategy. Train them to handle common issues independently, such as MFA re-registration or lost device procedures. This reduces help desk tickets, minimizes downtime, and encourages users to actively secure their accounts and devices.

Use RMM to test conditional policies and rollback changes

Before deploying Conditional Access policies across the organization, use your Remote Monitoring and Management (RMM) tool to test them on a small pilot group. This lets you detect friction early, monitor user experience, and roll back changes quickly if needed.

Troubleshooting

Here are common issues you may encounter while operationalizing Zero Trust security and how to address them:

Users blocked from apps

Conditional Access (CA) filters may block legitimate users if they don’t meet the defined conditions. Review both policy assignments and the filters (e.g., device compliance, location, user risk) to confirm why access was denied.

Device marked non-compliant

Devices may show as non-compliant if security features are missing or misconfigured. Common reasons include Microsoft Defender Antivirus, TPM, BitLocker, or baseline policy drift. Confirm that Defender Antivirus is running, TPM is available, BitLocker is enabled, and baseline policies are applied correctly.

GPO not applying

A GPO may fail to apply if it isn’t linked properly or the scope settings are misaligned. Run: gpresult /h report.html to generate a report of applied and denied policies.

📌 Note: 

Start-Process .\report.html

This will open the report.html file in the default browser, allowing you to review applied and denied GPOs in a clear, readable format.

Then confirm the GPO is linked to the correct OU, the scope is accurate, and loopback processing settings are correct.

MFA prompt loop

MFA loops often stem from session misconfigurations or token refresh issues. Check Conditional Access session settings (e.g., sign-in frequency and persistent browser session) and token refresh behavior for affected apps. Ensure that apps support modern authentication to avoid repeated MFA requests.

NinjaOne services

NinjaOne helps operationalize Zero Trust by:

With NinjaOne, MSPs can centralize device trust validation and automate Zero Trust enforcement across tenants without adding administrative or user friction.

Operationalize Zero Trust security to strengthen identity and endpoint protection

You can build a Zero Trust environment without frustrating users or overloading technicians. Conditional Access, PowerShell, GPO, and registry tagging combined with intelligent automation allow MSPs to enforce strong security controls with minimal user disruption.

This guide covered the core methods to operationalize Zero Trust security: creating adaptive Conditional Access policies, applying GPOs and registry settings for trusted endpoints, and using PowerShell to enforce and audit Zero Trust measures. It also highlighted how NinjaOne streamlines trust tagging, policy enforcement, and cross-tenant automation, strengthening the Zero Trust approach.

Related topics:

• How to Implement Zero Trust for Enhanced Cybersecurity: A Practical Guide
• How to Configure Conditional Access Policies in Azure AD
• What is Zero Trust Architecture: The Top IT Security Model Explained