Here's the part that changes the Tuesday-afternoon conversation. Under the CBW, the duty of care isn't something you can fully delegate to IT. Board members can be held personally accountable, supervisor the RDI (Rijksinspectie Digitale Infrastructuur) can direct measures at individual directors, and the fines reach up to 10 million euro or 2% of annual turnover. There's even a mandatory training obligation for directors. "In control" just became a word a director has to be able to defend, not a box IT ticks.

What the CBW actually asks of you

The law is short on buttons and long on outcomes. Three obligations do most of the work:

• Zorgplicht (duty of care). Run a risk analysis and take appropriate technical and organisational measures. It explicitly extends to your suppliers and chain partners, not just your own tenant.
• Meldplicht (incident reporting). A significant incident gets an early warning within 24 hours, a fuller report within 72 hours, and a final report within one month. (RDI: Meldplicht)
• Registratieplicht. You register your organisation with the supervisor so they know you exist and which regime you fall under.

For government bodies, the duty of care lines up with a standard you already know: the Baseline Informatiebeveiliging Overheid, BIO2. And that's where "in control" gets concrete. BIO2 tells you what must be true. It does not tell you which setting in Microsoft 365 makes it true, or how to prove it still is.

That gap is the whole problem. A policy binder that says "we enforce MFA" is not evidence. An auditor, and now a supervisor, wants the list: which measure, which setting, and a check anyone can re-run to see it's really there.

"In control" is a verb, not a binder

The uncomfortable truth about most compliance programmes is that they're built on assertion. Someone wrote "access is reviewed annually" in a document in 2023, and everyone has been nodding at it since. Nobody has run the query that proves a review actually recurred.

Being in control means the opposite: for every measure that matters, you can point at the setting and produce a read-only command that shows its live state. Not a screenshot from last quarter. The state, today, on demand.

So we built the thing that closes the gap between the BIO2 measure and the Microsoft 365 reality: the BIO2 control map. Every mapped government measure gets three things:

1. The concrete M365 setting that implements it (Conditional Access, a Purview retention policy, an Intune compliance policy, a PIM assignment).
2. The licence it needs, named exactly, because this is where claims quietly break.
3. A read-only PowerShell command you run in your own tenant to verify it. Trust, but verify.

It also does the honest thing most vendor mappings won't: it flags the measures where Microsoft 365 is not the answer. Backup (BIO2 8.13) is the clearest one. M365 has retention, versioning and a recycle bin, none of which is a backup that survives ransomware or a bad bulk edit that syncs perfectly. Ticking that box with "it's in the cloud" is exactly the kind of assumption a supervisor is now empowered to punish.

You don't need the most expensive licence to be in control

Here's the myth worth killing before it costs you a renewal: that CBW readiness means buying Microsoft 365 E5 for everyone. It doesn't.

Walk the control map and a pattern shows up. A large share of the provable measures sit on licences you very likely already own:

• Conditional Access MFA, device compliance, admin-portal protection, Terms of Use for provable acceptance of policies: Entra ID P1, which ships in Microsoft 365 Business Premium and E3.
• Intune compliance and app protection policies, removable-media control, endpoint hardening: Intune Plan 1, also in Business Premium and E3.
• Unified audit log, DKIM and DMARC, sensitivity labels, retention policies, Secure Score: included or in E3.

E5 buys you the long tail: automatic labelling, Audit (Premium) retention beyond 180 days, Defender XDR, attack simulation training. Real value, but not the entry ticket. The sharper move is to know which control sits on which shelf, prove everything your current licence already covers, and make a deliberate, documented decision about the gaps, rather than panic-buying the top SKU. The control map names the shelf for every measure, and the companion Licensing tool decodes the SKUs.

The one number that moves: prove the trend

You can't screenshot "in control." But you can produce a signal that changes over time, which is exactly what a PDCA cycle and a board report need. In Microsoft 365 that signal is Microsoft Secure Score, and it's read-only, licence-included, and has history.

This is the smallest possible "prove it" you can run today. It won't make you compliant, but it turns "we're improving our security posture" from a sentence into a line on a graph.

<#
.SYNOPSIS
    Pulls the Microsoft Secure Score trend so you can show posture over time,
    not a single point-in-time claim. Read-only.

.DESCRIPTION
    Secure Score is the one built-in M365 measurement with history per control.
    The trend is the evidence a board report and a PDCA cycle actually need:
    proof the line moves, in the right direction. This does not change anything.

.NOTES
    Required Graph scope : SecurityEvents.Read.All
    Module               : Microsoft.Graph.Security

    Secure Score is NOT a BIO2 score. It's a useful trend to underpin your
    'in control' story, never a compliance percentage. The weighting is
    Microsoft's, not the BIO2's.
#>

Connect-MgGraph -Scopes SecurityEvents.Read.All

# The trend is the evidence, not the snapshot. Grab the last 12 measurements.
Get-MgSecuritySecureScore -Top 12 |
    Select-Object CreatedDateTime, CurrentScore, MaxScore,
        @{n = 'Percentage'; e = { [math]::Round($_.CurrentScore / $_.MaxScore * 100, 1) } } |
    Sort-Object CreatedDateTime

A rising line is a fair thing to put in front of a director. A flat line since 2024 is a conversation you'd rather have with yourself than with the RDI. Just don't dress the percentage up as a BIO2 compliance figure: the weighting is Microsoft's, and a supervisor will know the difference.

Where to start before August 15

You have just over two weeks. Nobody closes NIS2 in two weeks, and anybody selling you that is selling. What you can do is stop guessing and start proving:

1. Run the Secure Score trend above. That's your baseline and your first board slide.
2. Open the BIO2 control map, filter to GEDEKT (covered), and run the read-only check for the measures you claim to have in place. Confirm the policy is actually enabled, not sitting in report-only.
3. Filter to NIET (not covered by M365) and write those down as deliberate decisions with a compensating control, not silent gaps. That list, honestly kept, is itself evidence of a working duty of care.

Being in control was never the day you configured the tenant carefully. It's the day you went back and checked, wrote down what you found, and could hand the whole thing to someone who's allowed to fine your director. The CBW just set a date on it.

Want the control map folded into a recurring, evidenced BIO2 baseline for your tenant before the deadline? Let me know.

Sources: Digitale Overheid, Cyberbeveiligingswet · RDI, Meldplicht Cyberbeveiligingswet · RDI, Bestuurlijke verantwoordelijkheid en governance. BIO2 measure text: bio-overheid.nl.

App registrations are the service accounts nobody offboards. They're non-human identities that authenticate with a secret or certificate, skip every MFA and conditional-access control you built for people, and hold whatever permissions they were granted on the day someone was in a hurry. A user who leaves gets offboarded. An app that outlives its purpose just keeps its keys.

Why stale app registrations are a real risk

An over-permissioned app registration is a better target than a user account. It has no phone to prompt, no password to rotate, and its credential is often sitting in a config file, a pipeline variable, or a wiki page. If that secret leaks and the app holds Mail.Read as an application permission, the attacker reads every mailbox in the tenant, not one. Consent granted once, in 2022, is still consent today.

This is exactly the surface auditors have started asking about: inventory of application identities, least privilege, and removal of what's no longer used. BIO2 and NIS2 both expect you to know which non-human identities exist, what they can do, and that you retire the ones that went dark. "We review our app registrations" is a policy. The auditor wants the list: every app, when it was created, whether anything still calls it, and which of them hold tenant-wide write permissions they've clearly never needed. Let's build that list.

Requested is not granted

Here's the distinction most app-registration audits get wrong, and it's the whole point of this one.

An app registration has two separate permission stories. requiredResourceAccess on the application is what the app asks for, the list you see under "API permissions" in the portal. The grants on its service principal are what the app can actually do in this tenant. They are not the same thing. An app can request Directory.ReadWrite.All in its manifest and never have been consented, in which case that scary-looking permission is a request nobody answered, not a live risk.

Read the manifest alone and you flag apps that can't do anything. Read the grants alone and you miss what an app is designed to reach for. You want both columns side by side: what it wanted, and what it got. The script resolves each API permission GUID to a real name like Mail.Read and marks whether it's actually granted, so Directory.ReadWrite.All (requested, not granted) reads very differently from Directory.ReadWrite.All (granted).

When a name comes back and you're not sure how much it really grants, the Least Privilege tool does that lookup by hand: every Graph permission, delegated versus application, admin consent or not, with the tenant-wide ones flagged.

The one signal that costs a licence, and the ones that don't

"Is anything still using this app?" comes from servicePrincipalSignInActivities, a Graph report that rolls up the last time a service principal signed in across delegated and app-only flows. It's the honest answer to whether an app is a live integration or a museum piece.

It's also the expensive part. That report is a /beta preview API, it needs an Entra ID P1 or P2 licence and the AuditLog.Read.All permission, and it doesn't exist in US Gov or 21Vianet clouds. Miss any of those and the call fails.

So the script treats sign-in activity as optional. When the report runs, you get a real UsageState verdict per app. When it can't, the app doesn't lie to you: UsageState comes back as Unknown rather than a confident-but-false NeverSignedIn, and everything else, the creation dates, the ages, the requested-versus-granted permissions, still comes back on any tenant, licence or not. That last part matters, because two of the most damning findings, "created four years ago" and "holds Application.ReadWrite.All and has an expired secret," need no premium licence at all.

One honesty caveat baked into the verdict: the sign-in report isn't backfilled. NeverSignedIn means "no activity on record," not "provably never used." Read it as a strong hint to investigate, not a death certificate.

The script

Read-only. It pulls every app registration, resolves its permissions to names, checks what's actually granted, folds in sign-in activity when it can, and flags the apps holding high-privilege permissions. Nothing is changed. By default it skips Microsoft-published apps, because your own registrations are almost always what you're auditing.

<#
.SYNOPSIS
    Inventories every app registration in an Entra ID tenant: when it was created,
    whether it's still being used, and which API permissions it holds.

.DESCRIPTION
    Builds one report row per app registration (/applications) with creation date and
    age, last sign-in activity and a UsageState verdict, the API permissions the app
    both requests and has actually been granted (GUIDs resolved to names like
    'Mail.Read'), and credential expiry. Read-only: it changes nothing.

    Requested vs. granted matters. requiredResourceAccess on the application is what the
    app asks for; the grants on its service principal are what it can really do. An app
    can request Directory.ReadWrite.All and never have been consented.

    Sign-in activity comes from /beta/reports/servicePrincipalSignInActivities, which is
    preview-only and needs Entra ID P1/P2. If that call fails the report still runs and
    UsageState comes back as 'Unknown' rather than a misleading 'NeverSignedIn'.

.NOTES
    Required Graph scopes : Application.Read.All, Directory.Read.All, AuditLog.Read.All
    Required Entra role   : Global Reader (or Reports Reader + Application Administrator)
    Modules               : Microsoft.Graph.Authentication, Microsoft.Graph.Applications

    AuditLog.Read.All is only needed for sign-in activity; omit it with -SkipSignInActivity.
    The sign-in report is a /beta preview API, not available in US Gov or 21Vianet clouds.
#>

[CmdletBinding()]
param(
    [ValidateRange(1, 3650)]
    [int] $UnusedAfterDays = 90,

    [switch] $IncludeMicrosoftApps,

    [string] $CsvPath,

    [string] $PermissionCsvPath,

    [switch] $SkipSignInActivity
)

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'

#region Connection

$requiredScopes = @('Application.Read.All', 'Directory.Read.All')
if (-not $SkipSignInActivity) { $requiredScopes += 'AuditLog.Read.All' }

$context = Get-MgContext
if (-not $context) {
    Write-Verbose "No Graph session; connecting with: $($requiredScopes -join ', ')"
    Connect-MgGraph -Scopes $requiredScopes -NoWelcome
    $context = Get-MgContext
}
else {
    # Reuse the caller's session, but only if it can actually do the job. Directory.Read.All
    # is a superset of Application.Read.All, so accept either.
    $granted = @($context.Scopes)
    $effective = $granted + $(if ($granted -contains 'Directory.Read.All') { 'Application.Read.All' })
    $missing = $requiredScopes | Where-Object { $_ -notin $effective }

    if ($missing) {
        Write-Verbose "Existing session is missing: $($missing -join ', '). Reconnecting."
        Connect-MgGraph -Scopes $requiredScopes -NoWelcome
        $context = Get-MgContext
    }
}
Write-Verbose "Tenant: $($context.TenantId) as $($context.Account)"

#endregion

#region Reference data

# Well-known permissions that make an app a real problem if it's compromised. Used only
# to flag rows for triage, a starting point for review, not a security verdict.
#
# Type matters, so there are two lists. Delegated permissions are bounded by the
# signed-in user; application permissions are not. Mail.Read delegated reads the user's
# own mailbox; Mail.Read as an application permission reads every mailbox in the tenant.

# Dangerous either way: admin-consent, tenant-wide write permissions.
$highPrivilegeAlways = @(
    'Application.ReadWrite.All', 'AppRoleAssignment.ReadWrite.All', 'Directory.ReadWrite.All',
    'RoleManagement.ReadWrite.Directory', 'PrivilegedAccess.ReadWrite.AzureADGroup',
    'User.ReadWrite.All', 'Group.ReadWrite.All', 'GroupMember.ReadWrite.All',
    'Domain.ReadWrite.All', 'Policy.ReadWrite.ConditionalAccess', 'Sites.FullControl.All',
    'DeviceManagementConfiguration.ReadWrite.All', 'DeviceManagementManagedDevices.ReadWrite.All'
)

# Only dangerous as application permissions, where "All" means the whole tenant rather
# than the one user who consented.
$highPrivilegeAsApplication = @(
    'Mail.Read', 'Mail.ReadWrite', 'Mail.Send', 'MailboxSettings.ReadWrite',
    'Files.Read.All', 'Files.ReadWrite.All', 'Sites.Read.All', 'Sites.ReadWrite.All',
    'Calendars.ReadWrite', 'Contacts.ReadWrite'
)

function Test-HighPrivilegePermission {
    param(
        [Parameter(Mandatory)][AllowEmptyString()][string] $Name,
        [Parameter(Mandatory)][string] $Type
    )
    if ($Name -in $highPrivilegeAlways) { return $true }
    return $Type -eq 'Application' -and $Name -in $highPrivilegeAsApplication
}

# Resource service principals are shared across apps (nearly every app points at Microsoft
# Graph), so resolve each one once. Without this, a few hundred apps means thousands of calls.
$resourceSpCache = @{}

function Get-ResourceServicePrincipal {
    param([Parameter(Mandatory)][string] $ResourceAppId)

    if ($resourceSpCache.ContainsKey($ResourceAppId)) {
        return $resourceSpCache[$ResourceAppId]
    }

    $sp = $null
    try {
        $sp = Get-MgServicePrincipal -Filter "appId eq '$ResourceAppId'" `
            -Property 'id,appId,displayName,appRoles,oauth2PermissionScopes' `
            -ErrorAction Stop | Select-Object -First 1
    }
    catch {
        Write-Warning "Could not resolve resource app $ResourceAppId : $($_.Exception.Message)"
    }

    $resourceSpCache[$ResourceAppId] = $sp
    return $sp
}

#endregion

#region Sign-in activity

# appId -> lastSignInDateTime. Keyed by appId because that's the only field that ties the
# report back to an application; the report's own id is an opaque encoding.
$signInByAppId = @{}
$signInDataAvailable = $false

if (-not $SkipSignInActivity) {
    Write-Verbose 'Retrieving service principal sign-in activity (beta preview report)...'
    try {
        $uri = 'https://graph.microsoft.com/beta/reports/servicePrincipalSignInActivities'
        while ($uri) {
            $response = Invoke-MgGraphRequest -Method GET -Uri $uri -ErrorAction Stop

            foreach ($entry in $response.value) {
                # lastSignInActivity is the roll-up across delegated/app-only and
                # client/resource flows: exactly the "is anything still calling this?"
                # question. Absent when the SP has no recorded activity at all.
                $last = $null
                if ($entry.ContainsKey('lastSignInActivity') -and $entry.lastSignInActivity) {
                    $last = $entry.lastSignInActivity.lastSignInDateTime
                }
                if ($entry.appId) {
                    $signInByAppId[$entry.appId] = $last
                }
            }

            $uri = if ($response.ContainsKey('@odata.nextLink')) { $response.'@odata.nextLink' } else { $null }
        }

        $signInDataAvailable = $true
        Write-Verbose "Sign-in activity retrieved for $($signInByAppId.Count) service principals."
    }
    catch {
        # Most likely: no Entra ID P1/P2, missing AuditLog.Read.All, or a sovereign cloud
        # where the preview report doesn't exist. Not fatal: the rest of the report is useful.
        Write-Warning "Sign-in activity unavailable, UsageState will be 'Unknown'. $($_.Exception.Message)"
        Write-Warning 'This report requires Entra ID P1/P2 and AuditLog.Read.All.'
    }
}

#endregion

#region Service principals for the tenant's own apps

# One pass to map appId -> SP. Needed both to know whether an app has an SP at all and to
# read what's actually been granted to it.
Write-Verbose 'Retrieving service principals...'
$spByAppId = @{}
Get-MgServicePrincipal -All -Property 'id,appId,displayName,accountEnabled' |
    ForEach-Object { $spByAppId[$_.AppId] = $_ }
Write-Verbose "Found $($spByAppId.Count) service principals."

#endregion

#region Applications

Write-Verbose 'Retrieving app registrations...'
# Get-MgApplication doesn't return createdDateTime by default, so ask for it explicitly.
$applications = Get-MgApplication -All -Property @(
    'id', 'appId', 'displayName', 'createdDateTime', 'signInAudience', 'publisherDomain',
    'requiredResourceAccess', 'passwordCredentials', 'keyCredentials', 'notes', 'tags'
)

if (-not $IncludeMicrosoftApps) {
    $before = $applications.Count
    $applications = $applications | Where-Object {
        $_.PublisherDomain -notmatch '(?i)^(microsoft\.com|sharepointonline\.com)$'
    }
    Write-Verbose "Excluded $($before - $applications.Count) Microsoft-published apps (use -IncludeMicrosoftApps to keep them)."
}

Write-Verbose "Processing $($applications.Count) app registrations..."

#endregion

$now = [DateTime]::UtcNow
$permissionRows = [System.Collections.Generic.List[object]]::new()
$results = [System.Collections.Generic.List[object]]::new()
$appIndex = 0

foreach ($app in $applications) {
    $appIndex++
    Write-Progress -Activity 'Inventorying app registrations' `
        -Status "$appIndex/$($applications.Count): $($app.DisplayName)" `
        -PercentComplete (($appIndex / [Math]::Max($applications.Count, 1)) * 100)

    $sp = $spByAppId[$app.AppId]

    #region Granted permissions (what the app can actually do)

    # Only meaningful if an SP exists: consent is recorded against the SP, not the app.
    $grantedAppRoleIds = @{}   # appRoleId -> $true
    $grantedScopes = @{}       # scope name -> $true

    if ($sp) {
        try {
            foreach ($assignment in Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -All) {
                $grantedAppRoleIds[$assignment.AppRoleId] = $true
            }
        }
        catch {
            Write-Warning "Could not read app role assignments for '$($app.DisplayName)': $($_.Exception.Message)"
        }

        try {
            # Read via the SP's own navigation property rather than Get-MgOauth2PermissionGrant,
            # which lives in Microsoft.Graph.Identity.SignIns: not worth a third module
            # dependency for one call.
            $grantUri = "https://graph.microsoft.com/v1.0/servicePrincipals/$($sp.Id)/oauth2PermissionGrants"
            while ($grantUri) {
                $grantResponse = Invoke-MgGraphRequest -Method GET -Uri $grantUri -ErrorAction Stop
                foreach ($grant in $grantResponse.value) {
                    # scope is a space-delimited string; a grant exists per resource and per
                    # consent type (AllPrincipals = admin consent, Principal = a single user).
                    if (-not $grant.scope) { continue }
                    foreach ($scope in ($grant.scope -split '\s+' | Where-Object { $_ })) {
                        $grantedScopes[$scope] = $true
                    }
                }
                $grantUri = if ($grantResponse.ContainsKey('@odata.nextLink')) { $grantResponse.'@odata.nextLink' } else { $null }
            }
        }
        catch {
            Write-Warning "Could not read delegated grants for '$($app.DisplayName)': $($_.Exception.Message)"
        }
    }

    #endregion

    #region Requested permissions, resolved to names

    $permissions = [System.Collections.Generic.List[object]]::new()

    foreach ($required in @($app.RequiredResourceAccess)) {
        $resourceSp = Get-ResourceServicePrincipal -ResourceAppId $required.ResourceAppId
        $resourceName = if ($resourceSp) { $resourceSp.DisplayName } else { "Unknown ($($required.ResourceAppId))" }

        foreach ($access in @($required.ResourceAccess)) {
            # 'Role'  = application permission (app-only, no user present).
            # 'Scope' = delegated permission (acts on behalf of a signed-in user).
            $isAppRole = $access.Type -eq 'Role'
            $permissionName = $null
            $isGranted = $false

            if ($resourceSp) {
                if ($isAppRole) {
                    $role = $resourceSp.AppRoles | Where-Object { $_.Id -eq $access.Id } | Select-Object -First 1
                    if ($role) { $permissionName = $role.Value }
                    $isGranted = $grantedAppRoleIds.ContainsKey($access.Id)
                }
                else {
                    $scope = $resourceSp.Oauth2PermissionScopes | Where-Object { $_.Id -eq $access.Id } | Select-Object -First 1
                    if ($scope) { $permissionName = $scope.Value }
                    if ($permissionName) { $isGranted = $grantedScopes.ContainsKey($permissionName) }
                }
            }

            # Fall back to the GUID so an unresolvable permission is still visible rather
            # than silently dropped from the report.
            if (-not $permissionName) { $permissionName = "($($access.Id))" }

            $permissions.Add([pscustomobject]@{
                ResourceName   = $resourceName
                ResourceAppId  = $required.ResourceAppId
                PermissionName = $permissionName
                PermissionType = if ($isAppRole) { 'Application' } else { 'Delegated' }
                IsGranted      = $isGranted
            })
        }
    }

    foreach ($permission in $permissions) {
        $permissionRows.Add([pscustomobject]@{
            AppDisplayName = $app.DisplayName
            AppId          = $app.AppId
            ResourceName   = $permission.ResourceName
            PermissionName = $permission.PermissionName
            PermissionType = $permission.PermissionType
            IsGranted      = $permission.IsGranted
        })
    }

    #endregion

    #region Usage verdict

    $lastSignIn = $null
    $daysSinceSignIn = $null

    if ($signInByAppId.ContainsKey($app.AppId) -and $signInByAppId[$app.AppId]) {
        $lastSignIn = [DateTime]$signInByAppId[$app.AppId]
        $daysSinceSignIn = [Math]::Round(($now - $lastSignIn.ToUniversalTime()).TotalDays)
    }

    $usageState =
        if (-not $sp)                          { 'NoServicePrincipal' }  # can't sign in here at all
        elseif (-not $signInDataAvailable)     { 'Unknown' }             # report didn't run
        elseif ($null -eq $lastSignIn)         { 'NeverSignedIn' }       # no activity on record
        elseif ($daysSinceSignIn -le $UnusedAfterDays) { 'Active' }
        else                                   { 'Stale' }

    #endregion

    #region Credentials

    $credentials = @(@($app.PasswordCredentials) + @($app.KeyCredentials) | Where-Object { $_ })
    $activeCredentials = @($credentials | Where-Object { $_.EndDateTime -and [DateTime]$_.EndDateTime -gt $now })
    $nextExpiry = $activeCredentials | Sort-Object EndDateTime | Select-Object -First 1

    #endregion

    $createdDateTime = if ($app.CreatedDateTime) { [DateTime]$app.CreatedDateTime } else { $null }

    $results.Add([pscustomobject]@{
        DisplayName               = $app.DisplayName
        AppId                     = $app.AppId
        ObjectId                  = $app.Id
        CreatedDateTime           = $createdDateTime
        AgeInDays                 = if ($createdDateTime) { [Math]::Round(($now - $createdDateTime.ToUniversalTime()).TotalDays) } else { $null }
        UsageState                = $usageState
        LastSignInDateTime        = $lastSignIn
        DaysSinceLastSignIn       = $daysSinceSignIn
        ServicePrincipalId        = if ($sp) { $sp.Id } else { $null }
        AccountEnabled            = if ($sp) { $sp.AccountEnabled } else { $null }
        SignInAudience            = $app.SignInAudience
        PublisherDomain           = $app.PublisherDomain
        PermissionCount           = $permissions.Count
        GrantedPermissionCount    = @($permissions | Where-Object { $_.IsGranted }).Count
        ApplicationPermissions    = ($permissions | Where-Object { $_.PermissionType -eq 'Application' } | ForEach-Object { $_.PermissionName } | Sort-Object -Unique) -join '; '
        DelegatedPermissions      = ($permissions | Where-Object { $_.PermissionType -eq 'Delegated' } | ForEach-Object { $_.PermissionName } | Sort-Object -Unique) -join '; '
        GrantedPermissions        = ($permissions | Where-Object { $_.IsGranted } | ForEach-Object { $_.PermissionName } | Sort-Object -Unique) -join '; '
        HasHighPrivilegePermission = [bool]@($permissions | Where-Object {
            $_.IsGranted -and (Test-HighPrivilegePermission -Name $_.PermissionName -Type $_.PermissionType)
        }).Count
        SecretCount               = @($app.PasswordCredentials).Where({ $_ }).Count
        CertificateCount          = @($app.KeyCredentials).Where({ $_ }).Count
        HasValidCredential        = $activeCredentials.Count -gt 0
        NextCredentialExpiry      = if ($nextExpiry) { [DateTime]$nextExpiry.EndDateTime } else { $null }
        Permissions               = $permissions   # kept for pipeline use; dropped on CSV export
    })
}

Write-Progress -Activity 'Inventorying app registrations' -Completed

#region Output

if ($CsvPath) {
    # Permissions is a nested object collection and would export as a type name.
    $results |
        Select-Object -ExcludeProperty Permissions |
        Export-Csv -Path $CsvPath -NoTypeInformation -Encoding UTF8
    Write-Verbose "Wrote app inventory to $CsvPath"
}

if ($PermissionCsvPath) {
    $permissionRows | Export-Csv -Path $PermissionCsvPath -NoTypeInformation -Encoding UTF8
    Write-Verbose "Wrote $($permissionRows.Count) permission rows to $PermissionCsvPath"
}

$summary = $results | Group-Object UsageState | Sort-Object Name
Write-Verbose "Summary: $(($summary | ForEach-Object { "$($_.Name)=$($_.Count)" }) -join ', ')"

$results

#endregion

Reading the result

The report is one object per app, so pipe it however you think. But the value is in a few columns read together.

The single query that earns the whole script is the cleanup shortlist: apps that are stale but still dangerous.

# Stale apps that still hold high-privilege permissions. Start your review here.
.\EntraID-Discover-AppRegistrations.ps1 |
    Where-Object { $_.UsageState -eq 'Stale' -and $_.HasHighPrivilegePermission } |
    Sort-Object DaysSinceLastSignIn -Descending |
    Format-Table DisplayName, DaysSinceLastSignIn, GrantedPermissions

Nothing calling it in months, and it can still rewrite your directory. That's the row you take to the app owner, if you can still find one.

For pivoting the other way, "show me every app that holds Mail.ReadWrite," export the long-format permission list and filter that:

.\EntraID-Discover-AppRegistrations.ps1 -PermissionCsvPath .\perms.csv
Import-Csv .\perms.csv | Where-Object { $_.PermissionName -eq 'Mail.ReadWrite' -and $_.IsGranted -eq 'True' }

No Entra Premium, or you only want the free signals? Run it with -SkipSignInActivity. You lose the UsageState verdict, but you keep every creation date, every requested-versus-granted permission, and every credential expiry, which is still enough to find the four-year-old app holding Application.ReadWrite.All. That split, which answers sit behind P1/P2 and which you can get for nothing, is mapped out per feature in Licensing.

From list to action

Don't mass-delete app registrations. Deleting an app that turns out to run payroll at 2am on the last day of the month is a bad afternoon, and the sign-in report isn't backfilled, so a fresh NeverSignedIn might just mean "no activity recorded yet."

Disable first, the same pattern that works for stale users. Set accountEnabled to false on the app's service principal (not the application object) and the app can't authenticate, instantly and reversibly. Give it a few weeks. If nothing breaks and nobody shouts, delete it. The export you saved is your worklist now and your audit trail later: this is the before, the disabled apps are the after, and the ones still standing are the ones you deliberately kept.

And before you disable, use the columns you have to ask the owner one real question: "this app was created in 2022, hasn't signed in for 300 days, and can read every mailbox in the tenant, do we still need it?" Most of the time the answer is a sheepish no. That last clause is the one that lands, so it pays to get it right: Least Privilege spells out what a given permission actually reaches, and flags the ones that reach the whole tenant.

Prove it, don't assume it

You almost certainly have more app registrations than people who remember creating them, and some of them can do far more than anything they're still used for. That's not a failure of process, it's just what happens when the easiest identity to create is also the one nobody's job it is to retire.

Run the inventory once and you'll have your shortlist by the end of the coffee. Run it on a schedule and you turn "we review our app registrations" from a sentence in a policy into a CSV you can hand an auditor. Least privilege isn't the day you consented carefully. It's the day you went back and checked.

Want this folded into a recurring review, or into a broader baseline assessment of your tenant's non-human identities? Let me know.

Guests are the easiest thing to add in Microsoft 365 and the easiest thing to forget. Every one of them is an external identity with a foothold in your tenant, and the pile only ever grows in one direction. Nobody offboards a guest.

Why inactive guest accounts are a real risk

A guest account isn't a harmless placeholder. It can hold membership in Teams, access to SharePoint sites, and permissions on shared content, all authenticated from an identity you don't control and can't enforce a password policy on. When that external account gets phished, or the partner company has a breach, the blast radius is your data, reached through a door you left open.

For anyone thinking in framework terms, this sits right on top of the parts auditors actually poke at: management of inactive accounts, least privilege, and periodic access reviews. BIO2 and NIS2 both expect you to know who has access and to pull it when it's no longer needed. "We invite guests as needed" is a policy. The auditor wants the list of guests who haven't signed in since 2023, and proof you did something about them. Let's build that list.

How Entra tells you a guest went dark

The signal lives in one property: signInActivity. It carries three timestamps worth knowing:

• lastSuccessfulSignInDateTime is the last time the account actually got in. This is the one you want. It's been available since December 2023, and it isn't backfilled, so older accounts may be blank here.
• lastSignInDateTime is the last interactive sign-in attempt, successful or not.
• lastNonInteractiveSignInDateTime covers token refreshes and background client activity.

There's one behaviour that trips people up: signInActivity is not returned at all for an account that has never signed in. So a blank isn't a bug, it's a category. A guest with no sign-in activity either never accepted the invite or never used it, which for our purposes is the worst kind of stale. When the property is empty, we fall back to createdDateTime: invited this long ago, never once seen.

Mind the licence. The sign-in timestamps in signInActivity require an Entra ID P1 or P2 licence and the AuditLog.Read.All permission. Without both, Graph returns that field empty for every user, and suddenly your whole tenant looks like it never signed in. If every guest comes back as "never signed in," don't panic and mass-disable: check your licensing and scopes first.

No Entra Premium? You still catch the worst offenders

Here's the good news for tenants without P1/P2. The sign-in dates need the licence, but two of the most useful signals don't. createdDateTime (when the guest was invited) and externalUserState (whether they ever accepted) are ordinary directory properties that come back on any tenant, free.

That means even with no Entra Premium anywhere in sight, you can reliably surface the single most removable thing in your directory: guests invited months ago who never accepted the invite. A guest sitting at PendingAcceptance for 400 days was never in play. You don't need a sign-in timestamp to know that account is dead weight. What you lose without the licence is the subtler distinction between "accepted and active" and "accepted and dormant." The obvious junk still shows up.

The script leans into this. It checks once whether signInActivity is actually coming back, and only then adds the licensed columns (LastSuccessfulSignIn, LastInteractiveSignIn, and a NeverSignedIn flag) to the export. On a Premium tenant your CSV carries the sign-in evidence; on a tenant without it those columns are absent entirely, so nobody mistakes an empty field for a confirmed "never signed in." Same script, honest output either way.

The measurement

Read-only, no changes to anything. Pull every guest, work out when each was last genuinely seen, and keep the ones past your cutoff. Note that we filter on userType, not on signInActivity. The sign-in field can't be combined with other filters, so we grab it with -Property and do the date maths ourselves.

<#
.SYNOPSIS
    Finds stale Entra ID guest accounts and reports which ones to block.

.DESCRIPTION
    Pulls every guest user, works out when each was last genuinely seen (last
    successful sign-in, or the invite date when a guest never signed in), and
    exports the accounts past a chosen inactivity threshold. Read-only: it
    reports, it changes nothing. When the tenant is licensed for it, the export
    gains extra sign-in columns; without the licence those columns are simply
    left off, so the report never lies about data it doesn't have.

.NOTES
    Requires the Microsoft.Graph.Authentication and Microsoft.Graph.Users modules.
    signInActivity dates need an Entra ID P1/P2 licence and AuditLog.Read.All.
    The invite date (createdDateTime) and acceptance state (externalUserState)
    work on any tenant, so pending, never-accepted guests surface without a licence.
#>

Connect-MgGraph -Scopes "User.Read.All", "AuditLog.Read.All"

$DaysInactive = 90
$cutoff = (Get-Date).AddDays(-$DaysInactive)

# 1) Every guest, with sign-in activity and the date they were invited
$props = "id,displayName,userPrincipalName,mail,accountEnabled,createdDateTime,externalUserState,signInActivity"
$guests = Get-MgUser -All -Filter "userType eq 'Guest'" -Property $props

# Is sign-in activity actually coming back? It stays empty on tenants without an
# Entra ID P1/P2 licence. Decide once, so every row gets the same set of columns.
$hasSignInData = [bool]($guests.SignInActivity | Where-Object { $_ })

# 2) Decide who is stale. No signInActivity means never signed in, so fall back to the invite date.
$report = foreach ($g in $guests) {

    $lastSeen = $g.SignInActivity.LastSuccessfulSignInDateTime
    if (-not $lastSeen) { $lastSeen = $g.SignInActivity.LastSignInDateTime }

    # Reference date: last real sign-in, or when the account was created if it never signed in
    $reference = if ($lastSeen) { [datetime]$lastSeen } else { [datetime]$g.CreatedDateTime }
    if ($reference -ge $cutoff) { continue }   # still active within the window, skip

    # Base columns work on any tenant, licence or not
    $row = [ordered]@{
        Id                = $g.Id   # the stable handle for actions; guest UPNs are awkward (#EXT#)
        DisplayName       = $g.DisplayName
        UserPrincipalName = $g.UserPrincipalName
        InviteState       = $g.ExternalUserState   # PendingAcceptance means never even accepted
        InvitedDaysAgo    = [int]((Get-Date) - [datetime]$g.CreatedDateTime).TotalDays
        AccountEnabled    = $g.AccountEnabled
        InactiveDays      = [int]((Get-Date) - $reference).TotalDays
    }

    # Licensed extras: add the real sign-in evidence as separate columns, only when it exists
    if ($hasSignInData) {
        $row['NeverSignedIn']        = [bool](-not $lastSeen)
        $row['LastSuccessfulSignIn'] = $g.SignInActivity.LastSuccessfulSignInDateTime
        $row['LastInteractiveSignIn'] = $g.SignInActivity.LastSignInDateTime
    }

    [pscustomobject]$row
}

# 3) Worst offenders on top, and keep the evidence
$report | Sort-Object InactiveDays -Descending | Format-Table -AutoSize
$report | Export-Csv .\inactive-guests.csv -NoTypeInformation -Encoding UTF8

Reading the result

Two columns tell most of the story:

The NeverSignedIn, LastSuccessfulSignIn, and LastInteractiveSignIn columns only appear when your tenant is licensed for sign-in data. If they're missing from your CSV, that's your answer on the licence, and InviteState plus InvitedDaysAgo are still doing honest work.

One nuance so you read it honestly: lastSignInDateTime reflects sign-ins to your directory and resources. A B2B guest can be busy in their own tenant and still show up here as inactive, which is exactly right, because it means they aren't touching your stuff.

From list to action

Disable before you delete. Blocking sign-in is instantly reversible; if someone shouts, you flip one property back. Deletion is a 30-day clock. And because these two steps land weeks apart, drive both from the CSV you exported, not from $report in memory, which is gone the moment you close the window. The export is your worklist, and later your audit trail.

Step one, block sign-in on everything in the list:

# Fresh session, write scope only. Blocking needs nothing more than this.
Connect-MgGraph -Scopes "User.ReadWrite.All"

# Read back the list you exported earlier, so this runs in any session.
$report = Import-Csv .\inactive-guests.csv

# Eyeball it. Happy? Block sign-in on every account.
# Target by Id, not UPN: guest UPNs carry the #EXT# format and are easy to fumble.
foreach ($g in $report) {
    Update-MgUser -UserId $g.Id -AccountEnabled:$false
    Write-Host "Blocked: $($g.UserPrincipalName)"
}

Now give it a couple of weeks. Nobody complained, nothing broke? Come back to the same CSV and remove the accounts that were never real to begin with, the ones that never accepted or have sat dark for months. The rest stay blocked, your safety net:

# Weeks later, a fresh session. Same export, same write scope.
Connect-MgGraph -Scopes "User.ReadWrite.All"

# Remove only the clear-cut cases; leave everything else blocked but recoverable.
Import-Csv .\inactive-guests.csv |
    Where-Object { $_.InviteState -eq 'PendingAcceptance' -or [int]$_.InactiveDays -gt 180 } |
    ForEach-Object {
        Remove-MgUser -UserId $_.Id
        Write-Host "Removed: $($_.UserPrincipalName)"
    }

Blocked, then deleted, is a clean and defensible audit trail. The export is your before, the disabled accounts are your after, and the ones still standing are the ones you deliberately kept.

Why not just use Microsoft's built-in report?

By now you might be wondering why you're running a script at all. Fair question. Entra does ship an inactive guest insights report, and Access Reviews can even disable and delete stale guests for you on a schedule. It's genuinely good tooling. It's also parked on the most expensive shelf in the store: the inactive guest report and the inactive-user Access Reviews need a Microsoft Entra ID Governance or Entra Suite licence, not the P1/P2 most tenants already own. And since January 2026, running a guest access review meters per guest through the Entra ID Governance for Guests add-on, so the tidy automation arrives with a line on your Azure bill.

The script asks for a lot less. The sign-in dates it reads come with plain P1/P2, and the never-accepted detection costs nothing at all. You get the same core answer, "which guests are dead weight," without buying the top SKU to find out. If you already own Governance, use the built-in reviews for the recurring workflow by all means. But you should never have to upgrade a licence just to answer a question your directory already knows.

From measurement to assurance

Running this once buys you a cleanup. The real win is repetition, because the guest pile refills the moment you look away, as every new project invites a few more. So schedule the measurement, wire an Access Review onto your guests, or at minimum make "does this guest still need to be here?" a recurring question with a CSV to answer it. Policy says you manage inactive accounts. The export proves you actually do.

Want this baked into a periodic access review, or folded into a broader baseline assessment of your tenant? Let me know.

Exchange Online is finally fixing this. Message center item MC1227623 announces a new PowerShell cmdlet, Invoke-ChangeMeetingOrganizer, rolling out worldwide between late June and July 2026 (GCC High and DoD follow through August). It transfers an existing meeting or series to a new organizer, who then gets full control: recurrence, attendees, description, everything. A user-facing version in Outlook and Teams is promised for later; the admin cmdlet arrives first, enabled by default, no configuration required.

This post covers how the transfer behaves, the gotchas that are easy to miss, a wrapper script that makes it safe to run, and the one thing that will stop you cold if you try it too early.

How the transfer behaves

The one-liner is simple enough:

Invoke-ChangeMeetingOrganizer -Identity frank@contoso.com -EventId AAMkAGRlMGI0 -NewOrganizer adele@contoso.com

Identity is the mailbox of the current organizer, EventId identifies the meeting, NewOrganizer is the receiving mailbox. The cmdlet supports -WhatIf and -Confirm, which you should absolutely use given what it touches.

The interesting behaviour is in what happens around that call:

• The transfer splits the series on a date. With -TransferSeriesStartDate you pick the effective date. Instances before that date stay untouched in the old organizer's calendar; everything from that date moves to the new organizer. Meeting history is preserved instead of orphaned. Note that this date cannot be in the past: the cmdlet rejects a start date earlier than today, so when in doubt, use tomorrow.
• Attendees inside your tenant notice almost nothing. Their existing calendar items are silently updated with the new organizer. No re-RSVP, and their personal tweaks to the item, such as reminder, category, show-as and private flag, survive.
• Attendees outside your tenant get the noisy version. They receive a cancellation truncating the old series, followed by a fresh invitation to the new one, plus extra messages for any series exceptions. They must re-accept. If your recurring meeting has external guests, plan the transfer and warn them.

The two gotchas in the design

The previous organizer is dropped from the meeting. After the transfer, the old organizer is no longer an attendee on the transferred portion. For offboarding that is exactly right. For a role change where the person still needs to attend, the new organizer has to re-invite them manually. Easy to miss, awkward to discover live.

Identifying the right meeting has sharp edges. The cmdlet takes either -EventId or -Subject. -Subject is the convenient path: match exactly one meeting and it transfers; match several and the cmdlet refuses to guess, returning the list of candidates so you can rerun with the precise -EventId. That is genuinely helpful, but two things bite. Subjects are rarely unique across a mailbox's history, so the ambiguous case is often the norm, not the edge. And the docs are explicit that -EventId "must identify the recurring series, not an individual instance" — hand it an instance id and it fails. The subject match is also scoped tightly: it only looks at meetings on the default calendar where -Identity is the actual organizer, so a meeting that mailbox merely attends returns No calendar events were found, not a hit. So a safe transfer is less a one-liner and more: try by subject, read what comes back, and confirm before committing.

Which is exactly what the script below wraps.

A wrapper that makes the transfer safe

You could call Invoke-ChangeMeetingOrganizer -Subject ... directly. This wrapper adds the guardrails you want around something irreversible: it verifies both mailboxes before touching anything, lets you drive the transfer by subject or by an exact EventId, keeps -WhatIf working end to end, and fails loudly instead of printing a cheerful success over an error. It needs a single module, ExchangeOnlineManagement — the cmdlet finds the meeting itself, so there is no second module to install and no second source of truth to drift.

#Requires -Modules ExchangeOnlineManagement

<#
.SYNOPSIS
    Transfers meeting ownership in Exchange Online, safely.
.DESCRIPTION
    Wraps Invoke-ChangeMeetingOrganizer. Identify the meeting by -Subject (the
    cmdlet transfers it when exactly one matches, or returns the candidates so
    you can pick) or directly by -EventId. Validates both mailboxes first and
    supports -WhatIf end to end.
.EXAMPLE
    .\Transfer-MeetingOrganizer.ps1 -CurrentOrganizer frank@contoso.com `
        -NewOrganizer adele@contoso.com -Subject "Weekly stand-up" -WhatIf
.EXAMPLE
    .\Transfer-MeetingOrganizer.ps1 -CurrentOrganizer frank@contoso.com `
        -NewOrganizer adele@contoso.com -EventId AAMkAGRlMGI0
#>
[CmdletBinding(SupportsShouldProcess, DefaultParameterSetName = 'BySubject')]
param(
    [Parameter(Mandatory)] [string] $CurrentOrganizer,
    [Parameter(Mandatory)] [string] $NewOrganizer,
    [Parameter(Mandatory, ParameterSetName = 'BySubject')] [string] $Subject,
    [Parameter(Mandatory, ParameterSetName = 'ByEventId')] [string] $EventId,
    [datetime] $TransferFrom = (Get-Date).Date.AddDays(1)
)

$ErrorActionPreference = "Stop"

# 1. Both mailboxes must exist before we touch anything
foreach ($upn in $CurrentOrganizer, $NewOrganizer) {
    $null = Get-EXOMailbox -Identity $upn
    Write-Host "  [ok] mailbox found: $upn"
}

# 2. Let the cmdlet identify the meeting: by EventId directly, or by Subject
#    (it transfers a single match, or returns the candidates to choose from).
$params = @{
    Identity                = $CurrentOrganizer
    NewOrganizer            = $NewOrganizer
    TransferSeriesStartDate = $TransferFrom
    Confirm                 = $false
    ErrorAction             = 'Stop'   # so "action is disabled" actually stops us
}
if ($PSCmdlet.ParameterSetName -eq 'ByEventId') {
    $params.EventId = $EventId
    $label = "EventId $EventId"
} else {
    $params.Subject = $Subject
    $label = "subject '$Subject'"
}

# 3. Transfer, honouring -WhatIf all the way down
$doel = "$label organised by $CurrentOrganizer -> $NewOrganizer, effective $($TransferFrom.ToShortDateString())"
if ($PSCmdlet.ShouldProcess($doel, "Transfer meeting organizer")) {

    $result = Invoke-ChangeMeetingOrganizer @params

    # A single-match transfer returns nothing. An ambiguous -Subject returns the
    # candidate meetings instead of acting, so surface them and stop.
    if ($result) {
        Write-Warning "Subject '$Subject' matched more than one meeting. Nothing was transferred."
        Write-Host   "Pick the right EventId below and rerun with -EventId:`n"
        $result | Format-List *
        return
    }

    Write-Host "`nTransferred: $doel"
    Write-Host "Remember:"
    Write-Host "  - $CurrentOrganizer is NO LONGER an attendee; re-invite manually if needed."
    Write-Host "  - External attendees receive a cancellation plus a new invite and must re-accept."
}

A few deliberate choices in there. The mailbox check up front fails fast on typos, before anything irreversible. Identifying the meeting is left to the cmdlet itself — -Subject for convenience, -EventId when you already know it — which is what drops the second module. Parameter sets make -Subject and -EventId mutually exclusive, so you cannot accidentally pass both. When a subject is ambiguous the cmdlet returns the candidates rather than acting; the script surfaces that list and stops, so you rerun with the exact -EventId instead of transferring the wrong series. Finally, -ErrorAction Stop on the transfer means a failure actually stops the script, rather than printing a cheerful "Transferred" over the top of an error, which is exactly the trap the next section is about.

The one that will stop you cold

Here is the thing the announcement does not tell you clearly enough: the cmdlet can be present in your module and still refuse to run. Run it before the feature has landed in your tenant and you get:

Invoke-ChangeMeetingOrganizer: ||Transfer meeting action is disabled.

That is not your session, your permissions, or your script. It is the MC1227623 rollout still in flight. The cmdlet ships with the Exchange Online module ahead of the server-side capability, so the command exists, accepts your parameters, resolves the meeting, and then the service declines at the last step.

Two things worth knowing here. First, there is no organisation-level switch to flip while you wait. Checking for one comes back empty:

Get-OrganizationConfig | Format-List *MeetingOrganizer*, *ChangeMeeting*
# (no matching properties)

No property means no toggle: this is purely gated by the rollout, not by a setting you forgot. Second, this is precisely why the script uses -ErrorAction Stop. Without it, Invoke-ChangeMeetingOrganizer writes "action is disabled" as a non-terminating error and the script sails on to print "Transferred" underneath, telling you the transfer succeeded when it did nothing. Fail loudly, or you will trust a lie.

So if you are reading this during the rollout window and hit "action is disabled": the plumbing is correct, the service simply is not ready. Try again in a few days with the exact same call.

One more trap from that same window, and this one wastes an afternoon if you let it: the disabled state does not always surface as the clean message above. The exact same call comes back sometimes as Transfer meeting action is disabled, and sometimes, with nothing changed, as a generic:

A server side error has occurred because of which the operation could not be completed. Please try again after some time. If the problem still persists, please reach out to MS support.

That message all but tells you to open a support ticket. Don't, yet. It is intermittent: during the rollout the service is simply unreliable about how it reports a feature that is not switched on, and repeating the identical call often returns the real reason instead. Do not expect -Verbose to save you here, either. It shows the HTTP round-trip, which is reassuring, but the same call under -Verbose still returns the bare "server side error" as often as not, because the wording is the server's choice, not yours. During the rollout window, read a "server side error" on an otherwise valid call as one more spelling of "not ready", not as a bug to escalate.

Make it part of offboarding, not firefighting

The real value of this cmdlet is not the one-off rescue, it is closing a structural gap. Offboarding processes are usually solid on licences, group memberships and mailbox conversion, and silent on the recurring meetings a person owns. Those only surface weeks later, when someone tries to move the stand-up and cannot.

So add one line to the offboarding checklist: transfer or cancel the recurring meetings this person organises. Transferring a series you can already name is the script above. Finding them all in the first place is a different job — the transfer cmdlet only acts on a meeting you can identify — so discover the mailbox's meetings first with Get-CalendarDiagnosticObjects, which stays inside the same Exchange module. Run it during offboarding, transfer what should live on, cancel the rest, and the three-year-old zombie series never gets the chance to exist.

Sources: MC1227623, Invoke-ChangeMeetingOrganizer on Microsoft Learn, Roadmap 554937.

Why this is a real risk

A shared mailbox is supposed to be a mailbox without an owner: people access it through their own account with delegated permissions. The underlying Entra account is a technical by-product and should be blocked for sign-in. In practice, this goes wrong in two ways:

• Converted mailboxes. An employee leaves, the mailbox is converted to shared "so we can still get to it". The account stays enabled, the password stays valid, and sometimes even the license lingers. You now have a sign-in-capable account that nobody is watching anymore, often without MFA registration from an active owner.
• Manually created mailboxes where the "block sign-in" step was skipped. The password is system-generated and unknown, sure, but unknown is not the same as unusable: whoever has the rights to reset passwords has an inconspicuous way in.

For those who think in framework terms: this directly touches the management of inactive accounts and least privilege. An auditor who asks about this does not want to see a policy, but a list. We are going to make that list now.

The measurement

The nasty part is that you cannot see this in a single console. Exchange knows the mailbox, Entra knows the account and the licenses. So: pull the shared mailboxes from Exchange Online, per mailbox do the crosswalk to Entra via the ExternalDirectoryObjectId, and check AccountEnabled and the licenses there.

# Required: ExchangeOnlineManagement and Microsoft.Graph.Users
Connect-ExchangeOnline
Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"

# 1) All shared mailboxes from Exchange
$shared = Get-EXOMailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited |
    Select-Object DisplayName, PrimarySmtpAddress, ExternalDirectoryObjectId

# 2) Crosswalk to Entra: is the account enabled, and are there licenses attached?
$report = foreach ($m in $shared) {
    try {
        $u = Get-MgUser -UserId $m.ExternalDirectoryObjectId `
             -Property Id, DisplayName, AccountEnabled, UserType, AssignedLicenses

        [pscustomobject]@{
            Mailbox        = $m.DisplayName
            Address        = $m.PrimarySmtpAddress
            AccountEnabled = $u.AccountEnabled
            Licenses       = @($u.AssignedLicenses).Count
            Verdict        = if ($u.AccountEnabled)              { "SIGN-IN ENABLED" }
                             elseif (@($u.AssignedLicenses).Count) { "LICENSED" }
                             else                                  { "OK" }
        }
    }
    catch {
        [pscustomobject]@{
            Mailbox = $m.DisplayName; Address = $m.PrimarySmtpAddress
            AccountEnabled = $null; Licenses = $null
            Verdict = "Not found in Graph"
        }
    }
}

# 3) Worst cases on top, and record the results
$report | Sort-Object Verdict | Format-Table -AutoSize
$report | Export-Csv .\shared-mailbox-measurement.csv -NoTypeInformation -Encoding UTF8

Reading the result

The Verdict column tells you where the work is:

Blocking is a single line:

Update-MgUser -UserId <objectId> -AccountEnabled:$false

And to those who think "we catch this with Conditional Access": maybe. But a blocked account is a guarantee, a CA policy is a configuration that can change. For accounts that should never sign in, the block is the only correct layer, with CA as the safety net on top of it, not the other way around.

From measurement to assurance

Running this script once gives you a cleanup action. The real gain is in repetition: every mailbox converted after today reintroduces the risk. So schedule the measurement periodically, or better: make blocking the account a fixed step in your offboarding and conversion process, and use the measurement as a check on that. Policy says what should happen; the export shows what has happened.

Questions about this script, or want to know how something like this fits into a broader baseline assessment? Let me know.

I work daily in Microsoft 365 environments where compliance is not a paper exercise but a requirement: BIO2, NIS2, and the Dutch Cybersecurity Act. What stands out most in that work is the gap between thinking everything is configured correctly and being able to prove that it is. Almost every organization has policies. Far fewer organizations can demonstrate, on any random Tuesday afternoon, that their tenant actually complies with those policies.

That gap is what this blog is about.

What you'll find here

The topics will be familiar if you've already looked around this site:

• Microsoft 365 governance: ownership, lifecycle management, external sharing, and why a decision log is often more valuable than a thick policy document.
• Compliance frameworks in practice: what BIO2 and NIS2 actually mean for a Microsoft 365 tenant, translated into configuration instead of intention.
• Automation with PowerShell: measuring configuration instead of assuming it, using tools such as Microsoft365DSC, Microsoft Graph, and the familiar PowerShell modules.
• Azure: where it intersects with the modern workplace, from Conditional Access to logging.

You won't find rewrites of product announcements or "10 tips" listicles. Instead, you'll find real-world scenarios I've encountered, worked out into something you can reproduce yourself.

Publishing cadence

I'm aiming for a weekly schedule, with the usual caveat that client work comes first. If you don't want to miss a post, there's an RSS feed, and I announce the larger articles on LinkedIn.

Have a question or a topic you'd like to see covered? Get in touch.

There is one small piece of friction, though. Maester lets you override the severity and the title of every test through a maester-config.json file. Maintaining that JSON by hand is tedious, error-prone, and worst of all it silently drifts out of sync with your actual tests the moment someone adds a new one.

This post shows a tiny PowerShell script that removes that friction entirely: it reads your test files, figures out which tests exist, looks up the severity for each of them, and writes a fresh maester-config.json for you. Run it as part of your build and the config can never fall behind again.

The problem in one picture

Maester's per-test overrides live in a file that looks roughly like this:

{
  "TestSettings": [
    {
      "Id": "MFA-001",
      "Severity": "Critical",
      "Title": "MFA-001 - Require MFA for privileged roles"
    },
    {
      "Id": "SPO-004",
      "Severity": "Medium",
      "Title": "SPO-004 - Restrict external sharing"
    }
  ]
}

Every object binds a test Id to a Severity (Critical, High, Medium, Low, Info) and a display Title. Maester uses those values when it renders the report and when it decides how loud a failure should be.

Now imagine a repository with dozens of custom tests spread across many files. Keeping this list correct by hand means:

• Remembering to add an entry every time you write a test.
• Removing entries for tests you deleted.
• Keeping the title in the JSON identical to the title in the test.
• Never fat-fingering a severity.

That is exactly the kind of bookkeeping a computer should do.

The idea

The trick is to treat your test files as the single source of truth and generate the config from them. That only works if your tests follow a small, predictable naming convention. A convention like this is easy to adopt and pays off immediately:

Describe 'Evaluating multi-factor authentication' {

    It 'MFA-001: Require MFA for privileged roles' -Tag "Entra ID", "Access control" {
        # ... your assertions ...
    }
}

The important part is the It line. Each test starts with a short, structured code (MFA-001), a colon, and a human-readable description. That single line gives us everything we need:

• The part before the colon (MFA-001) becomes the Id.
• The part after the colon becomes the description.

The script then builds the title as Id - description, so MFA-001: Require MFA for privileged roles becomes the title MFA-001 - Require MFA for privileged roles. Repeating the code in the title is deliberate: it means the Id is visible at a glance in the Maester report, not just in the raw config. If you would rather show only the description, drop the "$id - " prefix in the script — it is a one-line change.

The only thing still missing is the severity, and that lives in a separate lookup so that non-engineers can own it. More on that below.

A place to keep severities

Rather than hard-coding severities in the script, keep them in a simple mapping file. A two-column CSV is more than enough and can be edited by anyone, including people who do not touch PowerShell:

Id;Severity
MFA-001;Critical
SPO-004;Medium
EXO-002;High
LOG-001;Info

Tip: In practice this mapping file is a great place to also record why a control has a given severity, or to link it to whatever framework you report against (CIS, ISO 27001, NIS2, your own internal baseline). The script below only cares about the Id and Severity columns, so you can add as many extra columns as you like without changing a single line of code.

The script

Here is the whole thing. It is deliberately small, a little over fifty lines of PowerShell with no external modules.

# Stop on any error
$ErrorActionPreference = "Stop"

# Folder layout assumed here:
#   .\generate-maester-config.ps1   <- this script
#   .\severity-mapping.csv          <- Id;Severity lookup
#   ..\tests\Custom\*.Tests.ps1     <- your custom Pester tests

$scriptRoot = $PSScriptRoot
$repoRoot   = Split-Path -Parent $scriptRoot

# 1. Load the severity lookup into a hashtable for fast access
$csvPath = Join-Path -Path $scriptRoot -ChildPath "severity-mapping.csv"

$severityLookup = @{}
Import-Csv -Path $csvPath -Delimiter ";" | ForEach-Object {
    $severityLookup[$_.Id] = $_.Severity
}

# 2. Prepare the result set and the regex that recognises a test
$testSettings = [System.Collections.Generic.List[object]]::new()

# Matches:  It 'CODE-123: Some description' ...
$pattern = "^\s*It\s+'([A-Z]+-\d+):\s*(.*?)'"

# 3. Find every custom test file
$testsPath = Join-Path -Path $repoRoot -ChildPath "tests\Custom"
$files = Get-ChildItem -Path $testsPath -Recurse -Filter *.Tests.ps1

foreach ($file in $files) {
    foreach ($line in (Get-Content $file.FullName)) {
        if ($line -match $pattern) {
            $id    = $matches[1]
            $desc  = $matches[2]
            $title = "$id - $desc"

            # Look up the severity, fall back gracefully if it's missing
            $severity = $severityLookup[$id]
            if (-not $severity) {
                $severity = "Unknown"
                Write-Warning "No severity found for $id"
            }

            $testSettings.Add([PSCustomObject]@{
                Id       = $id
                Severity = $severity
                Title    = $title
            })

            Write-Host "  [+] $title ($severity)"
        }
    }
}

if ($testSettings.Count -eq 0) {
    Write-Warning "No tests found. Does your It-pattern look like  It 'CODE-123: Description' ?"
    return
}

# 4. Build the JSON and write it next to your tests
$json = @{ TestSettings = $testSettings } | ConvertTo-Json -Depth 3
$outputPath = Join-Path -Path $testsPath -ChildPath "maester-config.json"
$json | Out-File -FilePath $outputPath -Encoding UTF8

Write-Host "`nDone. $($testSettings.Count) test(s) written to maester-config.json"

How it works, step by step

1. Load the severities into a hashtable. Reading the CSV once into a @{} hashtable means every lookup afterwards is an instant key access instead of a repeated scan of the file. For a handful of tests it hardly matters; for hundreds it keeps things snappy.

2. Define the recognition pattern. The regex ^\s*It\s+'([A-Z]+-\d+):\s*(.*?)' is the heart of the script. It says: a line that starts with It, followed by a quoted string that begins with an uppercase code, a dash, some digits, a colon, and then the description. The two capture groups hand us the Id and the description directly. If your codes use a different shape (say numbers only, or a longer prefix), this one line is all you need to adjust.

3. Walk every test file. Get-ChildItem -Recurse -Filter *.Tests.ps1 collects your Pester test files (and only those, thanks to the .Tests.ps1 filter), and the script reads them line by line. Every line that matches the pattern becomes one entry in the result set. Because it works purely on text, it does not need to run your tests, so generating the config is fast and has no side effects on your tenant.

4. Fail loudly, then continue. If a test has no matching severity in the CSV, the script does not crash. It assigns Unknown and emits a Write-Warning. That way a forgotten mapping shows up as a visible nudge in your build log rather than a broken pipeline. You get the config and the reminder to fix the mapping.

5. Emit the JSON. Finally, ConvertTo-Json turns the collected objects into exactly the structure Maester expects, and it lands right next to your tests as maester-config.json.

A note on the collection. The results go into a System.Collections.Generic.List[object] rather than a plain $array += .... It is a small thing, but += rebuilds the entire array on every iteration, which is exactly the kind of quiet inefficiency you do not want in a script whose whole point is letting the machine do the tedious work. The list just grows.

Wiring it into your workflow

Because the script is idempotent and side-effect free, it fits anywhere:

• Locally, run it after adding a test so your config is always current before you commit.
• In CI, run it as a build step and either commit the result or fail the build if the generated file differs from the checked-in one. That turns "the config drifted" into a red pipeline instead of a silent bug.
• As a pre-commit hook, so nobody can forget.

A useful CI check is to regenerate and compare:

.\generate-maester-config.ps1
git diff --exit-code tests\Custom\maester-config.json

If that git diff returns a non-zero exit code, someone added or changed a test without regenerating the config, and CI will tell them.

Why bother?

A generated config buys you three things that a hand-written one never will:

1. It cannot drift. The config is derived from the tests, so it is correct by construction.
2. Severities become a shared, reviewable artefact. A CSV that non-engineers can edit means your security or compliance people can tune severities without opening a .ps1 file, and every change is visible in a pull request.
3. Onboarding is trivial. New tests just need to follow the naming convention. The plumbing takes care of itself.

The whole thing is a little over fifty lines of vanilla PowerShell, has no dependencies beyond what ships with the box, and works with any Maester setup that runs custom Pester tests. If you have been maintaining maester-config.json by hand, this is a small afternoon's work that you will be glad you did.

Have a different naming convention or a richer severity model? The regex and the lookup are the only two things you need to touch. Everything else stays the same.