How to run the Zero Trust Assessment

In Part 1, we focused on what the Microsoft Zero Trust Assessment is and why you’d use it.

Now we’re going to cross the line from theory into execution.

This part is all about actually getting the tool running in your tenant, in a way that’s secure, repeatable, and understandable to anyone who has to support it after you:

• Preparing the right environment
• Meeting the prerequisites
• Installing the ZeroTrustAssessment module
• Connecting it to Microsoft Graph and Azure
• Running the assessment and safely handling the results

By the end, you should be able to open PowerShell 7, follow a predictable set of steps, and end up with a working Zero Trust Assessment report in your environment.

Preparing Your Environment

Before you touch PowerShell, decide where this thing will live and what “good” looks like operationally. The Zero Trust Assessment is not a toy script.

It:

• Uses Microsoft Graph and Azure APIs to read deep configuration about your tenant
• Requires high-privilege roles (Global Admin for first run, Global Reader afterward)
• Stores sensitive security data locally while it runs and when it generates the report

That means the machine you run it on and the way you store the output are part of your security posture, not afterthoughts.

Choose the right machine

For most organizations, the “right” place to run it is:

• A hardened admin workstation
• Or a dedicated jump box used only by admins and security staff

Why?

• The tool will pull details about your users, devices, policies, Conditional Access, risk events, and more. If someone compromises that workstation, they now have a roadmap to your environment.
• The report itself can be used defensively or offensively. Microsoft explicitly warns that the report and export folder contain data that “threat actors might use to their advantage.”

What you want to avoid:

• Running this on random shared support PCs
• Running it on your daily-driver laptop that gets wiped, loaned, or used casually
• Running it on an ephemeral machine where nobody knows where the output went

Think about repeatability

Before running the Zero Trust Assessment, prepare the environment with the same care you would for any security-sensitive operation. The assessment will pull detailed configuration and identity data from your tenant. Hence, the machine you choose and the way you handle the output directly affect the safety and consistency of the process. The goal is to create a predictable, controlled setup that you can reuse for every future assessment.

Pick a reliable host machine

Start by selecting a stable and trusted device. This should not be a casual workstation or a shared machine. A hardened admin workstation or a dedicated jump box is ideal because it already follows stricter access controls and administrative boundaries. Avoid personal devices, user-facing endpoints, or anything that could be reimaged, shared, or exposed to unnecessary risk.

• Use a hardened admin workstation or dedicated jump box.
• Avoid shared, personal, or unmanaged machines.

Decide where your assessment reports will be stored

Next, establish a consistent location for storing both the temporary output and the final report. Creating a predictable folder structure helps with repeatability, auditing, and automation later. Many organizations use a local staging directory on the assessment machine and then move completed reports into a more secure, centrally managed repository.

• Use a standard staging folder such as C:\Assessments\ZeroTrust\YYYY-MM.
• Move completed reports to a secure location, such as a restricted SharePoint library or a protected file share.

Control who can run the assessment

Access to the assessment process should not be open to the public. Only individuals with a legitimate administrative or security role should be able to run the tool on the designated machine. This ensures control over permissions, protects sensitive output, and maintains the integrity of the assessment process.

• Restrict access to the assessment machine.
• Allow only the security team and key identity or endpoint administrators to run the tool.

By preparing your environment in this structured way, you create a stable foundation for consistently running the Zero Trust Assessment securely and with minimal friction in future cycles.

Meeting the Prerequisites

Before you install or run the Zero Trust Assessment module, ensure your environment meets the following prerequisites. Microsoft’s official guidance emphasizes this clearly: if you skip these steps, the module will fail in confusing ways, and you may find yourself staring at a PowerShell window that refuses to cooperate. Preparing your prerequisites properly ensures a smooth installation and prevents issues related to incompatible PowerShell versions, insufficient permissions, leftover modules, or missing dependencies.

To keep your environment clean and predictable, walk through the following areas carefully.

PowerShell 7 Requirements

The Zero Trust Assessment runs only on PowerShell 7 or later. It will not function in Windows PowerShell 5.1, even though both shells are available on most Windows systems. Using the wrong version is one of the most common causes of failure.

You can verify which version you are running by opening PowerShell and entering:

$PSVersionTable.PSVersion

• If the output shows a Major version of 7, your shell is compatible.
• If it shows 5.1, you are in the legacy Windows PowerShell environment.

If needed, install PowerShell 7 from the official Microsoft installer for Windows, macOS, or Linux.

Roles and Permissions

The Zero Trust Assessment requires elevated roles to read your tenant’s configuration, identity, and device information. Although the tool is read-only and does not modify settings, it still needs permission to access sensitive data.

Microsoft’s documentation outlines the required roles clearly:

• For the first run in a tenant:
  • Use a Global Administrator to grant the Microsoft Graph permissions the module needs.
• For all subsequent runs:
  • A Global Reader role is sufficient, provided consent was already granted during the initial execution.

This ensures the tool can access the necessary information while allowing you to limit privileged usage after the first configuration.

Cleaning Up Old Versions of the Assessment Module

If you previously used an early or preview version of the Zero Trust Assessment module, remove it before installing the latest version. Old modules can conflict with the current release, leading to version mismatches, unexpected errors, or inconsistent behavior.

In PowerShell 7, run:

Uninstall-Module ZeroTrustAssessment -Force -AllVersions

After uninstalling, close PowerShell 7 completely and reopen it. A clean session ensures the next installation does not pick up cached or partially removed modules.

Cleaning Up Microsoft Graph Modules (Optional but Helpful)

Some environments accumulate multiple versions of Microsoft Graph PowerShell modules over time. This can cause conflicts when the Zero Trust Assessment loads Graph dependencies. Microsoft and several partner guides recommend using a helper utility Uninstall-Graph to clear these modules out.

A typical cleanup sequence looks like this:

Install-Module Uninstall-Graph
Uninstall-Module ZeroTrustAssessment -Force -AllVersions
Uninstall-Graph

Once complete, restart PowerShell 7 and reinstall everything fresh. This step is optional, but it can prevent subtle dependency issues that are otherwise hard to diagnose.

Installing the Visual C++ Runtime on Clean Windows Machines

On some newly built Windows systems, you may encounter an error similar to:

Unable to load DLL ‘duckdb’
DllNotFoundException

This typically occurs when the required Microsoft Visual C++ 2015–2022 Redistributable (x64) is missing. Without it, specific components of the module, particularly DuckDB operations, cannot load.

The solution is straightforward:

• Install the Microsoft Visual C++ 2015–2022 Redistributable (x64).
• Rerun the assessment once installation is complete.

This resolves the missing DLL error and allows the module to operate normally.

Installing the Zero Trust Assessment Module

Once your prerequisites are in place, installing the Zero Trust Assessment module is straightforward. Even though the command itself is simple, it is still important to approach this step deliberately, just as you would with any change that interacts with security tooling. Understanding what the installation does behind the scenes helps you maintain control over your environment and ensures that the module is installed in the proper context.

What the Installation Actually Does

When you install the module, PowerShell retrieves it directly from the PowerShell Gallery, which is Microsoft’s official repository for PowerShell modules. The installation is scoped to your user profile, meaning it affects only the account performing the installation. This reduces risk and avoids unintentional interference with system-level modules or other users on the same machine.

Installing the module at the user level is intentional for several reasons:

• It does not require administrative elevation, making the installation safer and less intrusive.
• It keeps the module isolated to your account, which helps with change control and auditing.
• It allows you to install the module on a dedicated admin account without impacting other workspace environments.

This design makes it easier to maintain a clean, predictable configuration, primarily when multiple administrators operate in the same environment.

Running the Installation Command

To install the module, open PowerShell 7 and use the following command:

Install-Module ZeroTrustAssessment -Scope CurrentUser
Install-Module ZeroTrustAssessment -Scope CurrentUser -AllowClobber

If this is the first time you are pulling modules from the PowerShell Gallery on this machine, you may see a prompt that warns the gallery is an untrusted repository. If your internal policy permits it, approve the prompt to continue. The module will then be downloaded and installed in your user-specific PowerShell module directory.

Connecting the Tool to Your Tenant

Once the Zero Trust Assessment module is installed, it still does not know which tenant you want to assess. To establish that connection and allow the tool to read your environment securely, you must use the Connect-ZtAssessment command. This step is critical because it creates a secure, authenticated link between your PowerShell session and your Microsoft 365 tenant using Microsoft Graph and, when available, Microsoft Azure.

Without this connection, the assessment cannot retrieve identities, policies, device configurations, or logs, and the module remains effectively inactive.

What Connect-ZtAssessment Does

When you run the connection command, the module begins a two-stage authentication flow. First, it initiates a sign-in and consent process for Microsoft Graph, which is the API layer used to read configuration and security data across Entra ID, Intune, Conditional Access, and other Microsoft 365 services. Second, it opens a Microsoft Azure sign-in prompt, which is required for specific checks that depend on Azure resources, such as exported logs or diagnostic settings.

By completing these authentication steps, you allow the tool to access the following components in a read-only way:

• Your Entra ID directory
• Your Intune and device management configuration
• Your audit and sign-in logs, where applicable

This connection links the assessment tool to the identity, device, and logging fabric of your tenant, enabling it to collect accurate, comprehensive data.

Running the Connect Command

Open PowerShell 7 and run the following command:

Connect-ZtAssessment

The moment you execute this command, a browser-style Microsoft Graph authentication window appears. This is where you will complete the most essential part of the connection process.

Graph Sign-In and Consent

On the very first run of the assessment in a tenant, you must sign in with an account that has Global Administrator privileges. This is required so you can grant consent for the Microsoft Graph permissions the tool needs to function. The consent screen lists the specific read permissions requested, including items such as:

• AuditLog.Read.All
• Directory.Read.All
• DeviceManagementConfiguration.Read.All
• IdentityRiskEvent.Read.All

These permissions allow the tool to gather directory, device, configuration, and identity data. Once you accept the requested permissions, Microsoft creates a Microsoft Graph PowerShell application within your tenant that holds these read-only permissions. After this initial setup, the module will not prompt for consent again unless something changes.

On subsequent runs, you may sign in using a Global Reader account. Because the app already has consent, the connection will complete without requiring Global Administrator privileges.

Azure Sign-In and When It Matters

After completing the Graph sign-in, a second prompt appears for Microsoft Azure. This step is only required for tenants that actively use Azure resources.

If your tenant uses Azure services:

• Sign in using the same administrative account.
• Select the correct tenant and subscription when prompted.
• This enables checks related to log exports and Azure-based configuration.

If your organization does not use Azure at all:

• Close the Azure sign-in window.
• A warning may appear in the PowerShell console, but it can be safely ignored.
• The assessment will skip any tests that depend on Azure resources.

This flexibility ensures the tool can be used across a variety of environments, whether fully cloud-only, hybrid, or limited to Microsoft 365 workloads.

Managing Common Connection Issues

If you encounter problems during the connection process, the cause is usually straightforward. Most issues fall into one of the following categories:

• Wrong tenant or account
  It is easy to accidentally authenticate into the wrong tenant, especially if you manage several environments. Always verify the username and tenant name in the sign-in window.
• Incomplete Graph consent
  If you dismiss or close the consent prompt before accepting it, the setup will be incomplete. Run Connect-ZtAssessment and then sign in as a Global Administrator, and complete the consent workflow.
• Conflicting or outdated modules
  If the console hangs, errors out, or behaves inconsistently, you may have older versions of the Zero Trust Assessment module or conflicting Microsoft Graph modules installed. Clearing out those modules and restarting PowerShell usually resolves the issue.

Typical cleanup steps include:

• Removing old Zero Trust Assessment modules
• Removing or cleaning up Microsoft Graph modules
• Restarting PowerShell 7 before trying again

This ensures a fresh session with clean dependencies.

Running the Zero Trust Assessment

Once the module is installed and connected to your tenant, you can run the assessment. This is the step most administrators are eager to jump into first, but running it without proper preparation often leads to confusion and inconsistent results. Running the assessment collects a wide range of security and configuration data from across your tenant and produces a detailed report that reflects your current Zero Trust posture. Understanding what happens during the run, how long it may take, and what to expect during execution will help you avoid unnecessary interruptions or misinterpretations.

What Happens When You Run It

When you invoke the assessment, the tool begins a structured sequence of data collection and analysis across your tenant. It queries your identity configuration, device posture, authentication settings, audit logs, and other tenant metadata. These data points are then evaluated against Microsoft’s baseline Zero Trust controls and recommended security configurations. The goal is to identify strengths, gaps, and misconfigurations across identity, devices, access, and logging.

Even though the tool reads deeply into your environment, Microsoft explicitly states that the module is read-only. It does not modify policies, devices, accounts, or configurations. However, the visibility it has into your environment is significant, which is why the resulting report must be handled carefully.

When the assessment completes its checks, it writes all collected information to your local machine, along with the final HTML report that summarizes findings, scores, and recommendations.

Running the Basic Command

To run the assessment with default settings, open PowerShell 7 and execute:

Invoke-ZtAssessment

If you do not specify a path, the module uses your current working directory as the root location for output. During execution, it automatically creates a folder named “ZeroTrustReport” and, inside that folder, generates an HTML file called “ZeroTrustAssessmentReport.html“. After generating the report, it automatically opens the HTML file in your default browser for you to begin reviewing the results.

Customizing the Output Path

In most environments, you will want more control over where the assessment output is stored, especially if you plan to run it multiple times. You can use the -Path parameter to specify a parent directory for the results.

Example:

Invoke-ZtAssessment -Path "C:\Assessments\ZeroTrust\2025-01"

The module will then create a ZeroTrustReport folder under that directory. The resulting structure looks like:

C:\Assessments\ZeroTrust\2025-01\ZeroTrustReport\ZeroTrustAssessmentReport.html

Using a dedicated directory improves your ability to organize results by month, quarter, project team, or audit cycle. It also makes it easier to script or automate the transfer of reports into secure storage later.

Run Time Expectations

The duration of the assessment depends heavily on the size and complexity of your tenant. Microsoft states that assessments in large environments may run for several hours or even exceed 24 hours. Because the module performs hundreds of checks across authentication settings, device states, and policy configurations, long runtimes are expected.

During execution, you may see warnings regarding skipped tests. These occur when:

• Certain features are not licensed
• Azure resources are missing
• Configuration paths are unavailable
• Logs are not exported or cannot be accessed

You may also see transient errors that the module resolves on its own. These do not indicate a failure unless they halt execution entirely.

The key principle is simple:

Do not stop the assessment because you see warnings or non-critical errors. Only interrupt the tool if there is clear evidence that it has stopped progressing, such as no console output for an extended period and no CPU activity.

Securing and Cleaning Up the Output

Running the assessment generates detailed, sensitive information about your environment. The next step is to handle that output responsibly. Treating the report like any other sensitive security artifact is essential because it contains insights that could be misused if it falls into the wrong hands. Secure handling, proper storage, and deliberate cleanup are all part of completing the assessment process safely.

Why the Report Is Sensitive

The data collected and summarized in the report includes a range of configuration details that reveal your organization’s security posture. According to Microsoft’s guidance, the export contains information that a threat actor could use to plan attacks or identify weaknesses. For example, the report may include:

• Controls that are not configured or are configured weakly
• Indicators of identity or device risk
• Conditional Access gaps
• Sign-in and audit settings
• Policy details that describe enforcement levels

These insights are valuable for defenders and attackers alike. For that reason, the output should never be stored in unprotected locations or shared casually.

Moving the Output to a Secure Location

As soon as the report is generated, move the entire output folder to a secure repository. Do not move only the report file, as the folder often contains supporting data referenced by the HTML report.

Appropriate destinations include:

• A restricted SharePoint site available only to security or architecture teams
• A secured network file share with strictly controlled access
• A document management system with audit trails, retention policies, and access reviews

If your organization uses Microsoft Purview, apply a labeling policy to classify the report appropriately. A common choice is a sensitivity label such as “Confidential – Security Configuration.”

Cleaning Up the Admin Machine

Once you confirm that the output is securely stored, you should clean up the local system. The staging directory can hold sensitive information, and leaving it on the machine increases exposure risk.

Delete the entire output folder once it is no longer needed.

If you ran the assessment as a one-time activity, you can also remove the module:

Uninstall-Module ZeroTrustAssessment -Force -AllVersions

Microsoft’s documentation also describes how to remove the app registration and consent from Entra ID if the module will not be used again. However, if you plan to run the assessment regularly, it is more efficient to leave the module installed and maintain the consented application in place. In that case, only the temporary output folders need cleanup.

Bringing It All Together

At this stage, you have taken the Zero Trust Assessment from a conceptual tool to a fully executed process within your environment. You began by selecting a secure, consistent host machine, then ensured all prerequisites were met, including PowerShell 7 and appropriate permissions. You installed the module, connected it to your tenant through Microsoft Graph and Azure sign-ins, and successfully ran the assessment using Invoke-ZtAssessment. Afterward, you handled the report with the required level of security by storing it in a protected location and cleaning up the local environment.

By completing these steps, you now have firsthand experience running the assessment and generating a detailed, actionable report on your Zero Trust posture. This gives you a baseline to measure against in future cycles and provides concrete insights to strengthen your controls.