Maester: PowerShell Security Tests for Microsoft 365 Tenants

Who Maester is for and what it actually checks

Maester answers a narrow question: does this Microsoft 365 tenant still match the security configuration you intended? The README describes it as a PowerShell-based test automation framework for monitoring the security configuration of a Microsoft 365 environment. The unit of work is a test, and the test runner is Pester, so anyone comfortable with Pester output will recognise the results immediately.

The audience is administrators and security engineers who already work in PowerShell. If your team reviews tenant settings by clicking through the Microsoft 365 admin center, Maester converts that review into files you can diff, schedule and archive. The README lists automated testing, custom Pester tests, formatted results in CSV, Excel, HTML, JSON or Markdown, notifications to email, Teams or Slack, and execution inside GitHub, Azure DevOps or GitLab pipelines.

It is not an enforcement tool. Nothing in the README suggests Maester changes tenant settings. It reads configuration and reports a pass or fail per test, which means remediation stays a manual or separately scripted step.

Inside the PowerShell module and the test folder split

The architecture separates the engine from the tests. Source code lives in the powershell/ and tests/ folders at the repository root, and the build script assembles them into a publishable module. The tests themselves are installed into a folder on your machine rather than shipped inside the module, which is why the getting-started flow creates ~/maester-tests and then calls Install-MaesterTests.

That split matters for upgrades. The module version and the test version move independently, so Update-Module refreshes the engine while Update-MaesterTests refreshes the checks in the folder you installed them into. A new test added by the maintainers arrives through the second command, not the first.

The repository also contains a report/ folder and a website/ folder. The README notes that after changing the report you rebuild with ./build/Build-LocalMaester.ps1 -BuildReport, which builds and embeds the report template before importing the module. The module/ folder is described as a build artifact that is ignored by git and never committed; built modules are attached to GitHub releases and published to the PowerShell Gallery from CI. The primary language listed for the repository is HTML, which is consistent with a report template living alongside the PowerShell code.

A warning at the top of the README concerns the ExchangeOnlineManagement module: version 3.9.2 is called out as a known issue where many users experience connection errors, and the README states this is an issue with that module rather than Maester. That is a dependency risk you inherit, not one Maester controls.

Installing Maester and running your first tenant test

Installation is a single PowerShell Gallery command. Run it in a PowerShell session on a machine that can reach your tenant.

Install-Module -Name Maester -Scope CurrentUser

Next, create a folder for the tests and install them. The README notes that Pester will be installed if it is not already present.

md ~/maester-tests
cd ~/maester-tests
Install-MaesterTests

With the tests in place, connect to the tenant and run them. Connect-Maester establishes the session; Invoke-Maester executes the tests in the current folder.

cd ~/maester-tests
Connect-Maester
Invoke-Maester

If your tenant lives in a national cloud, Connect-Maester accepts an -Environment parameter. The README lists Global as the default plus China, USGov and USGovDOD.

Connect-Maester -Environment USGov

To keep the checks current, update the module and then update the test files in the folder where you installed them.

Update-Module Maester -Force
Import-Module Maester
Update-MaesterTests -Path ~/maester-tests

For pipeline use, Maester is published to the GitHub marketplace and can be called from a workflow. The README points to the action repository at maester365/maester-action and notes that the older action under maester365/maester is deprecated, with a deprecation notice at action/deprecation.md. If you copied a workflow from an older guide, that path is the one to check.

Where Maester stops being the right tool

The framework runs tests, and a test that fails does not fix anything. If your goal is drift correction rather than drift detection, Maester gives you the detection half and leaves the remediation half to you or to another tool.

Coverage is another boundary. The README says the Maester team adds new tests over time, which is an honest way of saying the test set is a moving target maintained by the project rather than a fixed specification. A configuration you care about may simply not have a test yet, and the documented answer is to write a custom Pester test yourself. That is a real cost: someone on your team needs Pester skills, not just portal skills.

There is also a dependency sensitivity that shows up in the README itself. The ExchangeOnlineManagement 3.9.2 warning means a routine module upgrade elsewhere in your environment can break Maester's connection step. Pinning that module is a workaround, and pinning carries its own maintenance burden.

Finally, Maester is PowerShell-first. Teams that have standardised on Python, Go or a cloud-native policy engine will be adding a second toolchain and a second credential path to their automation, which is a genuine argument against adopting it even when the checks themselves are useful.

Maester against a posture management service

The closest comparison is a hosted security posture management product for Microsoft 365, the kind that continuously evaluates configuration and presents findings in a web console with severity scoring and remediation guidance. The difference is where the logic lives and who owns it.

In a hosted service, the checks are defined by the vendor, the evaluation runs on the vendor's schedule, and the results sit in the vendor's interface. In Maester, the checks are files in a folder on your machine, the evaluation runs when you call Invoke-Maester, and the results are files you choose to produce: CSV, Excel, HTML, JSON or Markdown, per the README. That makes Maester easier to version alongside infrastructure code and easier to run inside a pipeline you already control.

The trade-off runs the other way too. A hosted service usually ships a user interface, historical trending and prioritisation that a folder of Pester tests does not provide out of the box. Maester's answer to history is the output formats and the CI integrations, which means you supply the storage and the comparison yourself.

A second, quieter alternative is doing nothing beyond the built-in Microsoft 365 security recommendations and your existing review habits. Maester is worth its setup cost only if you intend to run it repeatedly; a single manual review is faster without it.

Maintenance cost, licence and the update path

The last push to the repository was on 2026-08-26, and the recent releases listed are 2.2.40-preview, 2.2.39-preview and 2.2.38-preview, all dated 2026-08-26. Those are preview-tagged builds, so the release channel you consume deserves a look before you standardise on it.

The upgrade routine is two commands, and the split between them is the part teams get wrong: Update-Module Maester -Force refreshes the engine, and Update-MaesterTests -Path ~/maester-tests refreshes the tests in your folder. Skip the second and you keep running an old test set against a new module. Because the tests are files in a folder you own, local edits are possible, and any local edit will need reconciling the next time Update-MaesterTests runs.

The licence is MIT, which is permissive and places few conditions on internal or commercial use. The repository also carries a SECURITY.md, which is the file to read before reporting a vulnerability. Nothing here is legal advice; if you redistribute the module or embed it in a product, read the LICENSE file at the repository root yourself.

Editorial conclusion

Adopt Maester if your team already administers Microsoft 365 through PowerShell and wants configuration checks that can run on a schedule or inside a pipeline. Do not adopt it if you need a graphical compliance console, if you cannot grant a test identity read access to the tenant, or if your checks must run without PowerShell. Before rolling it out, verify which Microsoft Graph and Exchange Online permissions Connect-Maester requests in your tenant, and confirm that your ExchangeOnlineManagement module is not pinned to v3.9.2, which the README flags as a known issue.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes