Maester 3.0 Preview and Cloud: PowerShell 7.4 Requirements and Microsoft 365 Security Checks

Microsoft 365 admins, MSPs and anyone still running scheduled jobs on Windows PowerShell 5.1 should pay attention. Maester 3.0 changes the runtime requirement, the test format and how some results are classified.

What Maester is, briefly​

According to the project's GitHub repository, Maester is an open source PowerShell-based test automation framework designed to help you monitor and maintain the security configuration of your Microsoft 365 environment. Virtualization Review first covered it at version 0.1, when it only checked Conditional Access policies. It now covers much more.

According to the Virtualization Review report, Maester now covers:

• Microsoft 365 overall: 200+ Maester-native tests
• EIDSCA (Entra ID Security Config Analyzer): 44 tests
• CISA Secure Cloud Business Applications (SCuBA): 76 tests
• CIS Microsoft 365 Benchmark: 49 tests
• ORCA for Defender for Office 365: 67 tests
• Active Directory: 267 tests

Those counts come from the article. The project's own figures differ depending on what's counted. The Maester homepage advertises 888 built-in checks across CIS, CISA SCuBA, EIDSCA and ORCA, plus Microsoft's Zero Trust Assessment, while the 3.0 announcement cites 747 native tests. The homepage total appears to include the Zero Trust pack, which, per the homepage, runs Microsoft's assessment in its own PowerShell session and puts all 336 results next to Maester's checks. Treat any single number as a snapshot of a project that changes quickly.

The Active Directory suite is the notable expansion because it brings Maester to on-premises and hybrid environments. Virtualization Review notes two caveats. A normal interactive run excludes the AD tests, and pointing them at domain controllers takes some setup, especially for scheduled runs. As usual, read permissions are all it needs.

Section summary: Maester checks Microsoft 365, Entra, Defender for Office 365 and Active Directory against several frameworks. Test counts vary by source and by release.

Maester 2.3: the stable build, and a deadline that lands today​

Version 2.3 is the current stable release. Its official release notes list several changes:

• 14 preview checks for Microsoft Entra Agent ID, covering orphaned, unowned, inactive and over-privileged AI agent identities
• CIS Microsoft 365 Foundations Benchmark v7.0.0. Two controls move from Level 2 to Level 1, and the guest dynamic group control has been removed.
• An Affected Objects report, enabled with -IncludeAffectedObjects. It lists every user, group, app or Conditional Access policy behind your failed checks, sorted by severity.
• Security hardening after a privately reported flaw (GHSA-65g9-g8h8-qw5g). A crafted display name could inject script into the HTML report. The maintainers recommend that everyone update to 2.3 and run Update-MaesterTests.

The Affected Objects report changes the question from "which control failed?" to "which objects aren't protected?" That's usually the question your manager asks second.

The most time-sensitive item is MT.1197. According to the 2.3 release notes, it finds dynamic groups that use the memberOf rule operator. Microsoft's Message Center notice MC1488834 set November 3, 2026 as the retirement date. After that, those groups stop updating and their membership freezes. Licence assignments and Conditional Access policies that depend on them keep running against the frozen membership. If you haven't checked yet, run this:

Invoke-Maester -Tag "MT.1197"

The release notes add that the retirement also covers administrative units and entitlement management policies that use memberOf. MT.1197 only checks dynamic groups, so review those two areas separately.

Section summary: 2.3 is the build production automation should use today. If your tenant still uses memberOf dynamic groups, run MT.1197 now.

Maester 3.0 preview: new engine, new requirements​

The project's GitHub repository says the preview build on the PowerShell Gallery is now Maester 3.0. It has breaking changes: most notably, PowerShell 7.4 or later is required (Windows PowerShell 5.1 is no longer supported). The switch happened on schedule: Maester 3.0 merges into main on 8 October 2026 at 10:00 UTC, at which point the preview channel became 3.0. The maester.dev site lists both 3.0.0-preview and 2.3.0, and 2.3.0 is still the release build.

The main changes in 3.0, per the official announcement:

• Built-in engine instead of Pester. Checks are now native tests (Test.<ID>.ps1 and Test.<ID>.md). Each check is a PowerShell function paired with a Markdown file that holds the description and remediation steps.
• Tests ship inside the module. The repository says the tests ship inside the module, so there is nothing else to install or download. You no longer maintain a copied tests folder.
• Central connection and licence checks. The engine decides whether each test can run. On a tenant without Entra ID P2, for example, the risky sign-in MFA test is skipped with a reason code instead of showing up as a failure. The homepage describes this as a reason for every skip.
• Custom tests still work. Per GitHub, custom tests, including Pester tests, keep working; Convert-MtTest converts them to the new native format. Unconverted Pester tests need Pester 5.7.1 or later, which you now install yourself.
• Sequential for now. The scheduler is built for parallel runs, but 3.0 runs tests one at a time to stay close to 2.x behaviour.
• Layered configuration. According to the engine pull request, config layers merge: shipped defaults < maester-config.json < Custom/maester-config.json < maester-config.<tenantId>.json. MSPs get one base file plus per-tenant overrides.

Virtualization Review also highlights a live dashboard that shows run progress, weakest areas and an ETA. It also mentions framework tagging for audit prep, a documentation test builder with a licence explorer for finding service plan names, and three Maester Packs at launch, one of which wraps Microsoft's Zero Trust Assessment. The publication expects 3.0 to replace 2.3 as the release build around late November or early December, if the preview goes well. That's a projection, not a committed date.

A change that can skew your reports​

The official 3.0 announcement warns that a built-in test that throws an exception is now reported as Error, not Failed. After upgrading, your failure count may drop and your error count may rise without any change to your tenant. If you track posture over time or alert on failure counts, document this before the drop gets reported as an improvement.

Section summary: 3.0 is a rewrite. It requires PowerShell 7.4 or later, ships its tests inside the module and handles licence logic centrally. It's still a preview, and it can classify some results differently.

How to stay on stable, or test 3.0 safely​

To keep scheduled automation on 2.3:

1. Check whether you're on the preview channel. According to Merill Fernando's announcement, you are if you use Install-Module Maester -AllowPrerelease or Update-Module Maester -AllowPrerelease or maester_version: preview in the GitHub Action.
2. If so, switch to the release build: drop -AllowPrerelease or pin -RequiredVersion 2.3.0, and use maester_version: latest in the action.

To try 3.0 on a lab tenant or an interactive session:

1. Make sure the host runs PowerShell 7.4 or later. The repository notes that Maester runs on Windows, Linux or macOS.
2. Update and remove 2.x, then open a new session:
   
   Code:

   Update-Module Maester -AllowPrerelease -Force
   Uninstall-Module Maester -MaximumVersion 2.99.99 -AllVersions

3. Preview the cleanup with Update-MaesterTests -Path ./maester-tests -WhatIf, then run it without -WhatIf. It removes the old 2.x copies of the built-in tests and keeps your custom tests and config.
4. If you turned off built-in tests by deleting their files, turn them off in maester-config.json instead. Deleting files no longer works because the tests come from the module.
5. Install Pester 5.7.1 or later for Pester-format custom tests, or convert them with Convert-MtTest.
6. If a custom test calls a built-in Test-Mt* function, change it to Invoke-MtTest -Id <ID>. Those functions are no longer exported.
7. Run your usual command with -DryRun first. It lists every test that would run and the reason each of the others wouldn't.

What success looks like: a dry run that selects the tests you expect, skips the rest with clear reason codes, and no unexplained Error rows when you run it for real.

Maester Cloud: scheduled testing across tenants​

The author of the Virtualization Review piece identifies as "developer challenged." He says the hard part of using Maester across SMB clients has always been the automation. The docs cover GitHub, Azure DevOps, GitLab, Bitbucket and Azure Automation, but setting up recurring runs and comparing results is still real work. According to the article, Merill Fernando, Maester's lead architect, left Microsoft a few months ago and started Maester Cloud to handle that. The official 3.0 blog byline still lists him as a Microsoft product manager, so the byline may simply not have been updated.

As described by Virtualization Review:

• Deployment: you currently provide your own Azure subscription, and the service runs in a container instance. A SaaS version is coming.
• Tenant onboarding: a link for a sufficiently privileged admin to grant consent.
• Test governance: new tests are queued for approval (auto-approve is available). Per tenant, you can turn a test off, accept the risk with a reason, mitigations, owner and expiry date, or exclude it permanently from alerting.
• Break-glass accounts: a per-tenant picker for designating emergency access accounts.
• Email reports: sent from an Exchange Online shared mailbox.
• Cost: the author's nightly runs against five SMB tenants cost about AUD $2.50 (USD $1.75) over seven days. That's one person's figure, not a published price.
• Roadmap: an AI assistant for fixing failed tests, an MCP server, Jira and ServiceNow ticket sync, and importing tenants from Partner Center. These are planned, not shipped.

"Read-only," with an asterisk​

The article calls the permissions read-only. That's accurate for the part that runs every night, but not for setup. Maester Cloud's permission documentation says the runner app that performs assessments holds 21 Microsoft Graph application roles, all read-only. Setup is different. It uses delegated Application.ReadWrite.All and AppRoleAssignment.ReadWrite.All to create the sign-in and runner apps and grant the runner its roles. The documentation says a running deployment never uses those permissions again and that you can revoke them afterwards.

The docs offer three setup routes:

There's also a PowerShell route: Install-Module MaesterCloud, then Start-MaesterCloudSetup. It requires PowerShell 7.2 or later and signs in with Microsoft's own Azure CLI and Graph PowerShell apps, so your tenant never consents to a Maester Cloud application.

Two more details matter if you're doing a security review:

• Email: the service grants Application Mail.Send scoped to one shared mailbox. It doesn't grant tenant-wide Mail.Send in Entra.
• Optional Exchange, Teams and SharePoint connections: these add Exchange.ManageAsApp to the runner app, plus Sites.FullControl.All if you tick SharePoint. The runner also gets the Global Reader and Teams Reader roles. Sites.FullControl.All is not a read permission, so make that choice deliberately.

My recommendation (my own analysis, not the vendor's): use the Balanced route unless your identity team insists on least privilege. Afterwards, check the Maester Cloud Setup enterprise app in Entra to confirm the one-time permissions are gone.

Handle results like a penetration test report​

Virtualization Review makes a point that's easy to forget. Whether you run Maester locally or through Maester Cloud, the results map your tenant's gaps, and they would help an attacker. Keep reports out of public repos, ticket attachments sent to third parties and "quick look at this" emails. Version 2.3 adds -RedactUserIdentity, but its release notes say this is pseudonymization using an unsalted hash, not anonymization, and that email and Teams notifications aren't redacted.

The verdict​

Maester's strength is that it's community-run. The author argues that broad community authorship of tests is something most paid tools will struggle to match. He also reports that more than 60,000 tenants use Maester, about 40,000 run it daily, and Microsoft runs it against more than 70 of its game studio tenants. Those figures come from the article and weren't independently verified.

There are downsides. Maester Cloud is in preview, with UI bugs and setup documentation the author found thin, and a business model that's still forming. Pricing for the coming SaaS version will be based on monitored tenants and users.

Practical takeaways:

• Production pipelines: stay on 2.3.0 for now.
• Today: run MT.1197 before frozen memberOf groups quietly break licensing or Conditional Access.
• Lab: try 3.0 on PowerShell 7.4 or later, and use -DryRun before trusting any trend line.
• MSPs: Maester Cloud may finally make scheduled multi-tenant posture checks manageable. Read its setup permissions carefully before granting them.