Turn on automation

What you need

• The Automate plan: approved fixes and everyday admin, containment in one approved step, fixing automatically under a standing approval and containing taken-over accounts automatically all come with Automate. Monitor and the trial show every finding with its fix steps, but make no changes. They can still run a fix's dry run, to see exactly what it would change, and have Simulate policies. Exchange Online and Purview settings are read through the automation app, so their dry runs come with Automate. Moving from Automate to Monitor, or the end of a trial or subscription, cancels every change still waiting for approval or waiting to run, including leavers set for a later date. The plan page says how many before you move, and each member is told which. Automatic fixes and automatic containment stop, and stay stopped if you choose Automate again until an Owner or Admin starts them.
• The automation permissions, granted by the tenant's Global Administrator with a second, separate consent.
• Someone with the Admin or Owner role to approve changes that remove, disable or change a setting (or, for device actions, the Technician role). By default two different people must approve; the workspace owner can allow one person per tenant. Some higher-risk changes always need two. Changes that only add, and taking someone out of a group or a mailbox, run when asked, with no approval (see day-to-day admin).

1. Grant the automation permissions

Fixes are made by a second Microsoft app, ConfigCheckup Automation, that holds only the permissions to change settings. The first consent, which connects the tenant, is read-only; this one is separate, so a tenant can be assessed for as long as they like without granting anything that can write.

1. 1On the tenant's Changes › Automation page, the Automation card shows Step 1: automation permissions. Copy the automation consent link and send it to the tenant's Global Administrator.
2. 2They see Microsoft's consent screen listing only the write permissions, and accept. ConfigCheckup Automation then appears as its own entry under Enterprise applications in their tenant.
3. 3Select Check again. The step turns to Granted with the number of write permissions it holds.

Holding a write permission changes nothing by itself. The tenant can remove all of them at any time by deleting ConfigCheckup Automation in Entra; assessments carry on through the read-only app. Each action lists the permission it needs in the table below, and full details are in connecting a tenant.

Email records: connect the DNS host

SPF and DMARC are DNS records, so they are changed at the tenant's DNS host rather than in Microsoft 365. On the tenant's Settings tab, the DNS host card connects Cloudflare (an API token with DNS edit rights for the tenant's zones), Azure DNS (an app with the DNS Zone Contributor role on the resource group) or Amazon Route 53 (an IAM user limited to listing zones and changing record sets). The credential is checked with the host, stored encrypted and never shown again; an admin can disconnect it at any time, which deletes it.

The SPF and DMARC findings then offer the record to publish for each domain. Existing senders in an SPF record are kept, and other TXT records at the same name are left alone. Rolling back publishes the previous records.

The DKIM finding publishes the two CNAME records Exchange Online gives each domain and then turns signing on; it needs Exchange automation set up too. The MTA-STS finding publishes the _mta-sts record and points mta-sts. at ConfigCheckup, which serves the policy file itself. Start in testing mode, which refuses nothing, and move to enforce once it has run cleanly for a few weeks.

2. Switch it on per tenant

On the tenant's Changes › Automation page, find the Automation card and select Enable automation. This needs the Admin role, is recorded in the audit log, and can be switched off again at any time. It only appears once the automation permissions are granted.

3. Propose a fix

Fixes start as proposals. Anyone with the Consultant role can propose one:

• From a finding: select Fix this in Findings. Where the finding can be fixed for you, select Fix this on the finding: the dry run starts at once and shows on the finding when it is done. A change that only adds, or changes nothing, then runs. Otherwise, where your role may approve it and the tenant needs one approver, Approve and run approves it against the dry run you are shown and runs it straight away; where it needs someone else, Send for approval. Where the fix needs your choice first (which administrators lose Global Administrator, move to just-in-time access in PIM or get a cloud-only admin account, who owns ownerless groups, which stale groups to delete, the office IP ranges, which apps a workload identity policy covers, which Defender alerts to close and how to classify them, the default domain, or confirming the on-premises directory is retired), tick or type it in the finding and select Draft the change. Where the change starts on another page (Apps, People, Conditional Access), it links there; where it is done by hand, it says why and gives the steps.
• From Licence savings: Reclaim these licences drafts removal of licences from disabled and dormant accounts.
• From Device lifecycle: remove inactive end-of-life devices, disabling them first and deleting later.
• From Changes › Automation, under To do: every fix you can propose now across your tenants, grouped by fix, with Propose fix, Choose tenants or Propose all. Below it, Waiting on set-up lists the tenants with fixes held back until automation is switched on, resumed or granted its permissions, most to gain first.
• Across tenants: where a check with an automated fix fails at two or more tenants, Fix across tenants on Findings (and on the finding's fix step) prepares it at every one of them from one screen. See Fixing a check across tenants.
• From a tenant's Runbooks: Draft fixes drafts every fix the onboarding or monthly review still needs, and the compromised-account runbook drafts the containment changes for one account.
• Automatically, by a policy or a tenant's own switch: see Policies and simulations. Nothing runs until someone approves it.

Every proposal is dry-run straight away: ConfigCheckup reads the tenant and lists exactly what would change, and what would be skipped and why. A proposal whose dry run fails cannot be approved. A dry run only reads: anything in it that would change Microsoft 365, a DNS record, MTA-STS hosting or a Partner Center subscription is refused before it is sent. A check of a rollback reads the same way.

4. Approve and run

1. 1Submit the proposal. It appears on the tenant's Changes tab, and approvers are notified. Several drafts can go together with Send all for approval on that tab. Each still goes by its own rules: one whose dry run failed stays a draft, and one that only adds runs.
2. 2An Admin or Owner reviews the dry run and approves or rejects it with a comment. Whoever proposed a change is told when it is rejected, with the comment. By default two approvals are needed, and at least one must come from someone other than the person who proposed it. If you work alone, the workspace owner can change Who approves changes to one person in the Automation card on the tenant's Changes › Automation page; you then approve your own change after checking its dry run. Where you are the only person who can approve, connecting a new tenant asks you to choose one person or two, and Changes › Automation says so until it is settled. Some changes always need two different people, such as swapping licences, deleting a group or an account, or wiping a device, so they cannot be approved alone. Blocking sign-in and removing licences can be approved by the only Admin or Owner in a workspace that has one, where the tenant is set to one person and nobody they touch holds an admin role. Changes that only add, or that take one person out of a group or someone's access to a mailbox away, skip this step: they run as soon as they are asked for (see Day-to-day admin).
3. 3You can approve from three places, each against the dry run it shows you: the change's own page; the tenant's Changes tab, where an Admin or Owner can tick several and use Approve selected (or Reject selected, with one reason); or, once a change has one approval and needs a second, the row on Home's Needs you list, which counts only those. If a dry run was run again after you opened the page and came out differently, the approval is refused and you are asked to look again. A password reset, a full wipe and any change that asks you to type a name are approved only on their own page.
4. 4Once approved, the change runs. Just before it does, ConfigCheckup checks again that automation is on, the permissions are still granted and the targets are within limits. Each target's result is recorded, with the request that was made.
5. 5As soon as the change runs, ConfigCheckup reads back just the part of the tenant it changed, usually one or two requests, and checks every finding against it, so the tenant's score is updated within seconds. If Microsoft has not applied the change yet, it checks again after waits of 10 seconds, 30 seconds and 80 seconds, then 10 minutes, 60 minutes, 4 hours and 12 hours later, because Microsoft can take hours to show a change. Meanwhile the finding is awaiting confirmation: out of the open findings and never called failing. It is confirmed as soon as a check passes, and said to be still failing only after the last check,1032 minutes in all, with why. Secure Score recommendations, which Microsoft re-scores more slowly, wait for Microsoft and are checked once more 48 hours later, on the date shown. Changes approved together for one tenant are checked with one full assessment once the last of them has run. Once the check passes, the finding is resolved. If it still fails after the last check, you are told, with what to look at. A Conditional Access policy created in report-only mode enforces nothing, so its finding stays open until you switch the policy on; the change says so instead of reporting a failure.

Before a fix becomes a change, ConfigCheckup reads the setting live. If it is already in place, nothing is changed and the finding is read again. It closes when its check agrees. A record in DNS, such as SPF or DKIM, is read again once public DNS can show it, up to an hour later. An Intune policy already there under the fix's name counts only when it is assigned; one assigned to nobody is named, with where to assign it. If the check still fails, the fix is not offered again for 7 days, and the finding says what to check by hand. A change already waiting whose dry run, read again, finds nothing to change closes as Nothing to change, and whoever raised or approved it is told.

You don't need to reload. A change you approve shows its progress and then its result where you pressed the button, and the page you are on updates within a few seconds when a check finishes or a report is ready.

Reminders, and changes nobody decides on

A change waiting for approval is offered again a day after it was sent, to the people who can approve it, and after two days to every Admin and Owner. A draft, or a change waiting for approval, expires 14 days after it was proposed (or last sent for approval, which includes going back to waiting when its approvals stop counting) if no one has decided: it is closed, nothing is changed in Microsoft 365, and whoever proposed it is told. Each one says when it expires on its row and its page. A change that already has every approval it needs, held only because automation is off, say, does not expire; nor does one waiting for its scheduled time. Changes proposed before expiry began stay open until someone decides, and whoever proposed them was told so once.

Scheduling a change, and change windows

To run a change on a change-advisory date or out of hours, open Schedule for… when you send it for approval, when you approve it, or beside Approve selected and in the bar for drafts, and choose a time. The time is the tenant's own: set its time zone in the tenant's Settings › About this tenant, or it is the workspace's. With several tenants at once, the time is each tenant's own. Through the API, send scheduledFor with the draft. The change and every list say when it runs. Until then an approver can Change the time, Run now instead, or Unschedule it, which stops it running and sends it back for approval.

When its time comes, the change is dry-run against the tenant again first. If the dry run comes out differently from the one that was approved, it does not run: the approvals are cleared, as they are whenever a dry run changes, and whoever raised it and approved it are told, so it can be checked and approved again. It does not run either if the dry run fails, or if it no longer has the approvals it needs (the tenant now needs two people, say): it waits for approval. A change that needs no approval and whose dry run fails becomes a draft again, for whoever asked for it to run the dry run again and start it.

A tenant can also have a weekly change window, set in its Settings: the days, and a start and end time in the tenant's time zone, such as weekdays 18:00 to 22:00. Outside it, approved and automatic changes wait, shown as Held: outside the change window with when it opens, and run, dry-run again first, when it does. Containing an account and signing someone out run whatever the window. An Admin or Owner can run any approved change now with Run now: urgent, saying why; the reason is kept on the change and in the audit log. Urgent skips the window, never the approval. It holds for that run only: a change that goes back for approval, or is given a new time, waits for the window again unless it is marked urgent again.

Day-to-day admin: what runs without approval

A tenant's Users & mail tab has People, Groups, Mailboxes, Guests and Licences. Choose a person, group, mailbox, guest or licence and its panel lists what can be done. A Consultant, Technician, Admin or Owner can make the changes; a Viewer can only look.

• Changes that only add run straight away, with no approval: a new user, a new group, a new shared mailbox, adding people to groups and Teams (distribution lists and mail-enabled security groups included), adding a group owner, giving a licence, giving mailbox access (Full Access, Send As or Send on Behalf), sharing a calendar, inviting a guest and setting up a new starter like a colleague. Giving access to the mailbox of someone who holds an admin role is the exception: two different people approve it, including through Create a shared mailbox at the address of a shared mailbox that is already there. Letting someone who was blocked sign in again is not an addition: it goes to an approver (below). Each still has its dry run first, the checks just before it runs, the read-back, a way back from the change's page, and an audit log entry naming who asked for it.
• Taking one person out of a group or a distribution list, or taking someone's access to a mailbox or its calendar away, runs straight away too. Taking more than one person out of a group or a list in one change (up to 100, from Remove members or Take them out) goes to an approver, as many as the tenant's setting asks for, and so does taking a group or a contact off a calendar, as it takes everyone in it off. They lose what the group gave them, licences assigned through the group included. Its dry run checks who is there first, and rolling it back puts them back, with the group's licences. Straight after one person is taken out, the result offers Undo (see Rolling back).
• Asking devices to check in with Intune runs straight away too: ConfigCheckup changes nothing on the devices itself, so there is nothing to approve. A device that checks in picks up any policy waiting for it straight away, as it would at its next check-in. It still has its dry run and an audit log entry.
• Other changes that take something away, give access back or change a setting go to an approver, as many as the tenant's setting asks for: blocking sign-in or letting someone sign in again, signing someone out everywhere, resetting a password or MFA, resetting a class's passwords, offboarding a leaver, containing an account, turning off inbox rules that forward mail, taking more than one person out of a group or a list at once, taking someone off as a group's owner, sending a guest's invitation again, a mailbox's automatic reply, its forwarding (inside the organisation or out) or stopping it, its type or place in the address book, and every change to a policy or setting.
• Some always need two different people, whatever the tenant's setting, so they cannot be approved alone: deleting a group or an account, removing a guest, swapping a licence, and leavers in bulk. So do blocking sign-in and removing a licence, except in a workspace with one Owner or Admin, where the tenant is set to one person and nobody they touch holds an admin role.
• Where an account holds an admin role, or its roles cannot be read, two different people approve blocking it, signing it out, taking its licences back, resetting its password or MFA, letting it sign in again, offboarding it, removing its MFA methods in a containment, and changing its mailbox's settings. Offboarding someone in a group that can hold an admin role needs two too. So do forwarding mail outside the organisation, letting an account sign in again when a containment or the incident response runbook blocked it in the last 90 days, and a password reset and an MFA reset for the same person within a day of each other.

Several people at once. On People, tick the people, or choose Act on all for everyone in the list, and choose from the bar at the bottom: give a licence, add to a group, block or unblock sign-in, sign out everywhere, take a licence back, delete accounts, or offboard as leavers. Each is the same change as for one person, with its dry run, as few changes as Microsoft allows (a licence for 50 people at a time, a group for 100), and one change for each leaver. The same rules apply: adding runs straight away, and taking away or letting someone sign in again goes to an approver. The bar says who it leaves out, and why, before you start.

Leavers. Offboard as a leaver on a person makes every leaver step one change, sent to an approver. Choose their last day and it runs at 17:00 that day in the tenant's own time zone, or at the time you choose, once approved; a leaver asked for on the tenant portal runs at 17:00 on their last day too. It is dry-run again just before, and runs only if that matches what was approved. People lists the scheduled leavers at the top. Besides blocking sign-in, signing out, removing MFA methods, sharing the mailbox and reclaiming licences, it removes their admin roles (the last active Global Administrator always keeps the role), hides them from the address book, hands the groups and Teams they own to the person you name, adding the new owner before taking the leaver off, and takes away their Full Access, Send As and Send on Behalf on the other mailboxes ticked, which rolling back gives back. The dry run says how big the mailbox is before it becomes shared, and whether that is over 50 GB, and lists their devices; it warns when the account is synchronised from on-premises Active Directory, where it must be disabled too. Their devices are listed on the form as well: a Technician or above can retire or wipe each one, as a change of its own set for the same time, with all of a wipe's guards.

New starters. A joiner template on People says what a new starter in one role gets: licences, groups, mailbox access, a job title, a department and a usage location (the tenant's country unless the template says otherwise). New user can start from one, and Import starters takes a spreadsheet (CSV or Excel) with one starter a row: first name, last name, display name, sign-in address or nickname, job title, department, manager email and template name. The check says what each row makes and what is wrong with it before anything is made; then the rows that are right become changes of up to 25 people each. Mailbox access from a template follows about half an hour later, as a change of its own, once Exchange knows the new account. A new person shows on People a minute or so after their change runs: the check after a change reads the people, licences and groups again.

Changes drafted automatically, by an automation policy or a baseline, keep that policy's own rule, even when they only add. A group that can hold admin roles is never joined or left this way: the dry run leaves it out, so giving or taking away an admin role stays deliberate.

Fixing a check across tenants

When the same check fails at two or more tenants and has an automated fix, Findings offers Fix across tenants. It changes nothing about how each change is made: every tenant still gets its own proposal, its own dry run against its own tenant, its own approval and its own rollback.

1. 1The page lists every tenant where the check fails and whether the fix can be prepared there. Where it cannot, it says why: the tenant has not given the automation consent, automation is off or paused, the plan has no automation, the fix needs an input (a DNS host to connect, or a choice that belongs to that tenant), a change for the check is already open (with a link to it), or the tenant is a lead.
2. 2Every tenant that is ready is ticked. Untick any you want to leave out; a tenant where automation was declined for the check is listed but not ticked. For a fix that needs a choice, such as the DMARC mode or a policy's name, enter it once for all of them; what changes at each tenant (its domains, groups or apps) comes from its own finding. Fixes where who or what changes is chosen tenant by tenant, such as which administrators lose a role, are made from each tenant's finding instead.
3. 3Prepare drafts one change per tenant in the background, one tenant at a time, each dry-run against its own tenant. A tenant that already has a change open for the check is linked to it; nothing is drafted twice.
4. 4Review each tenant's dry run, tick the ones to approve and approve them together (an Admin or Owner, as for approving several changes at once). Each approval is recorded on its own change, for the dry run you were shown. A tenant that needs two people waits for a second approver, and the page says so. A change whose dry run failed, or whose dry run changed since you opened the page, cannot be approved from there.
5. 5The results show one row per tenant: waiting for a second approver, running, done and confirmed by reading the change back or by the check that follows, failed with Microsoft's reason, or rolled back. Changes still run one at a time in each tenant. Recent fixes across tenants are kept on the page, with who started each one, and starting and approving one are in the audit log.

Pilot tenants first

To try a fix at a few tenants before the rest, tick Run it at pilot tenants first and pick the pilots, or name a tag their tenants share. The pilots' changes run as soon as they are approved. Every other tenant's change waits, approved, as Held: waiting for the pilot tenants, until every pilot has run and reads back clean: each object it changed reads in Microsoft 365 as the change set it, or the check of its finding passes. Then the rest go on by themselves, or wait for an Admin or Owner to select Continue with the rest, as you chose. Each held change is checked against its tenant again before it runs, and runs only as approved.

If a pilot's change fails, is only partly made, reads back differently, still fails its check, or is rolled back or rejected, the rest stop and the Owners, Admins, whoever started the fix and the pilot tenants' account managers are told. A pilot that was ready may still fail later: Continue with the rest looks at the pilots again, and then asks why. Nothing more runs until someone decides: Continue the rest anyway (an Admin or Owner, saying why, recorded in the audit log), or roll back everywhere.

Changes that create accounts

Three changes create accounts: New user on People, cloud-only admin accounts for people whose admin roles sit on an account synchronised from on-premises, and emergency access accounts. Each account gets a long random password that is sent to Microsoft and never kept or shown, so nobody, ConfigCheckup included, knows it.

1. 1Once the change has run, open it under Changes. First sign-in for the new accounts lists them.
2. 2An Admin or Owner selects Issue a one-time access pass for an account. The pass is shown once, works for one sign-in within about 4 hours, and is never stored. Passes can be issued in the 7 days after the change ran; a new one can only be issued once the last has been used or has expired. Give it to the person directly, not by email.
3. 3They sign in at aka.ms/mysecurityinfo with the pass and register a passkey or security key. For emergency access accounts, register a FIDO2 key for each and keep the keys somewhere safe and separate.

Where Temporary Access Pass is not enabled in the tenant, an Admin or Owner can select Set a temporary password for a new user instead. ConfigCheckup makes a strong random password, sets it with “change at next sign-in” on, and shows it once with a copy button. It is never stored, logged or put in the audit log, which records only that one was set and for which account. It is offered for people's new accounts only, within the same 7 days, and only before they have set the account up; admin and emergency access accounts always use a pass. It needs the User-PasswordProfile.ReadWrite.All permission. Microsoft refuses to set an administrator's password unless ConfigCheckup Automation holds the Privileged Authentication Administrator role, and the console says so.

Password and MFA resets, device locks and wipes

A Technician, Admin or Owner can ask for any of these, from the tenant's Users & mail tab or a device's own page. None can be undone from ConfigCheckup, and the dry run says so.

• Password reset. ConfigCheckup makes a strong one-time password that the person must change when they next sign in, and signs them out everywhere unless you untick it. Admins and Owners approve it, as many as the tenant's setting asks for, except that an account with any directory role (a Global Administrator, for example) always needs two different approvers. Once approved, one of its approvers selects Reset password and show it once on the change's page and sees the password there, once. ConfigCheckup never stores, emails or logs it, so it is gone when the page is refreshed. Where the workspace owner allows it for a tenant, a reset can be approved from Teams or Slack; the password is still only shown in the console.
• Reset now. At a tenant that asks for one approver, an Admin or Owner who asks for a password reset can approve it and run it there and then from the person's panel, and sees the password once, without opening the change. It is never offered for a tenant that asks for two, an account that holds an admin role, or someone with an MFA reset asked for in the last day, and the audit log records that the same person asked and approved. It is offered for 30 minutes after the reset is checked, and until then a second reset for them is refused; after that, send it for approval instead.
• Reset MFA and issue an access pass. For someone already set up whose phone is lost or replaced, or whose account may be compromised: it removes every sign-in method they have registered, not their password, and, once approved, issues a one-time Temporary Access Pass so they can sign in once and register again at aka.ms/mysecurityinfo. It signs them out everywhere too unless you untick it. It takes their methods away, so Admins and Owners approve it, as many as the tenant's setting asks for and two for an account with a directory role, only in the console, never from Teams or Slack. The dry run lists each method, never a full phone number, and if one is registered after approval the change goes back for approval. One of its approvers runs it from the change's page and sees the pass there, once; ConfigCheckup never stores, emails or logs it. No pass is made for an account that holds an admin role or whose roles cannot be read, for an emergency access account, or when the person who asked for the reset runs it: the methods are still removed, and the result says why. A password reset and an MFA reset for the same person within a day always need two different approvers.
• A class's passwords. At a school, open a class on Groups and tick up to 30 pupils to reset their passwords in one change. Only accounts that hold student licences alone, are made in Microsoft 365, can sign in and hold no admin role are reset; anyone else is left out, saying why. It is approved on the change's page, never from Teams or Slack, and the approver who runs it sees every password once, each with a copy button. They are never stored, and cannot be printed or downloaded.
• Full wipe. Resets the device to factory settings, with the options you choose (keep enrolment data and keep user data are on by default; a six-digit unlock code for older Macs). It always needs two different approvers, at least one a Technician or above, each typing the device's name, in the console. It can never be approved from Teams or Slack. At most 5 full wipes run per workspace per hour; more wait for the hour to turn unless an Owner lets one run.
• Retire. The gentler choice: it removes company data, apps and management and leaves the person's own data. It is approved like the tenant's other changes, by a Technician or above.
• Lock. The gentlest: it locks a phone, tablet or Mac at once, and its owner unlocks it with their own passcode (a Mac, with the six-digit PIN Intune shows on the device's page). Nothing is removed. Intune cannot lock a Windows PC remotely, so retire or wipe one instead. A lock takes the device away from its owner until they unlock it, and ConfigCheckup cannot unlock it, so it is approved like the tenant's other changes, by a Technician or above, from Teams or Slack too.
• Lost or stolen device. Start from the person, on People: one form signs them out everywhere, locks, retires or wipes the device you choose, and marks it Lost or stolen on the asset register. Each step is its own change, dry-run and sent for approval at once. A device marked Lost or stolen says so first on its own page, with the same choices.
• Restart. Restarts a Windows PC through Intune. Anything unsaved on it may be lost, and a PC that asks for a BitLocker PIN at start-up needs someone there to type it. It is approved like the tenant's other device changes, by a Technician or above.
• Rename in Intune. Changes a company-owned Windows PC's own computer name, not joined to an on-premises domain, with a restart straight after if you tick it: Windows uses the new name after it restarts. The dry run says if the new name would move the PC into or out of a dynamic group or a Conditional Access policy that chooses devices by name, or what it could not check. It is approved like the other device changes and cannot be undone: rename it back as a new change. The name on the asset register is separate, and is never sent to Intune.

A device's own page. Scanning a device's asset label opens its page; so does a device on the Devices list, the asset register or a person's devices on People. Alerts comes first whenever something is wrong with it or something could not be read, then Asset (its record on the register, which a Technician or above edits), Device (everything the last assessment read from Intune and Entra ID) and Intune: check in now, restart, rename, lock, retire, wipe, and disable in Entra ID a device not seen for 90 days. Each is a change with its dry run and approval, on the exact Intune record shown where Intune lists the device twice. A device has one rename, restart, lock, retire or wipe open at a time. The remote actions ConfigCheckup does not send are listed there too, with the way to them in Intune.

Sync and remind. On the Devices list, filter to Non-compliant, tick devices and choose Sync and remind: each is asked to check in with Intune now, which changes nothing on it and so runs straight away, and its primary user gets an email from you, in your brand, asking them to open Company Portal and check its status. Replies come to you. A person gets at most one reminder a day.

Chase MFA. On People, filter to No MFA and choose Remind: each of them gets an email from you, in your brand, saying how to set up two-step sign-in at aka.ms/mysecurityinfo, and replies come to you. Tick Turn on the registration campaign as well and Microsoft asks them at their next sign-in; it is a setting for the whole tenant, so an approver says yes first. A person gets at most one reminder a day.

Microsoft Purview, if you switch it on

Sensitivity labels, data loss prevention, retention labels and labels on groups have no app permission, so ConfigCheckup makes them with Purview's admin commands. This is off unless an Admin switches Purview automation on in the tenant's Settings › Permissions, and the tenant gives the ConfigCheckup Automation app the Compliance Administrator role, which can change every Purview policy.

• Nothing the tenant already has is overwritten: a fix is skipped where the tenant has its own label policies, DLP policies (other than a policy for Microsoft 365 Copilot only) or retention labels. If label policies exist but publish nothing, the finding says what to turn on, and no second one is made.
• DLP policies start in test mode and block nothing until switched on in Microsoft Purview.
• Labels are published with none applied by default, and none encrypts or marks content. Retention labels only keep content.
• Microsoft reflects Purview changes in Secure Score slowly, so these fixes are checked once more 48 hours after the change.

Policies and simulations

A policy, set up under Changes › Automation › Policies, decides which fixes are drafted after each assessment: some checks or all of them, on every tenant or on tenants with any one of its tags, as a baseline does. It works in one of three modes:

• Simulate: ConfigCheckup records what it would draft, with each change's dry run, under Changes › Automation › Activity. Nothing is proposed. Start here. Simulate works on every plan: without Automate, every policy simulates, and the Automation page and an email each Monday say what Automate would have fixed in the last 7 days.
• Draft: each fix is drafted, dry-run and sent for approval. Where automation is off for a tenant, a drafting policy simulates there instead.
• Fix automatically: each fix runs on its own, approved in advance by the admin who set the policy. See below.

A tenant's own Draft fixes automatically switch, in its Settings, works like a drafting policy for every check on that tenant. At most 15 fixes are drafted, simulated or run per tenant in one assessment, most serious first.

Fixing automatically

A policy set to Fix automatically is a standing approval: an admin or owner approves its fixes in advance, in their own name. When an assessment finds a covered check failing, the fix runs without waiting for anyone. Where a control was passing and slips back, the drift check (settings every hour, and MFA registration and mail forwarding every 6 hours for tenants these policies cover) assesses the tenant again at once, so it is put right within hours.

Every safeguard still applies. A fix runs on its own only when:

• it can be rolled back in full and is not high-risk (removing licences, disabling accounts, a Windows upgrade that stays installed and the like always wait for a person);
• its dry run against the live tenant succeeds, and what ConfigCheckup knows about that tenant raises no risk: for example, nobody still sending with SMTP AUTH before it is turned off. Facts it could not read count as a risk;
• it changes no more objects than the policy's limit (25 unless you set another, up to 200);
• automation is on and not paused for the tenant, and the approver is still an active admin;
• for a tenant that needs two approvers, a second admin has co-signed the policy (select Co-sign beside it under Changes › Automation › Policies);
• the fix has not changed since the policy was approved. When ConfigCheckup changes the fix a check offers, Owners and Admins are told, and the policy drafts that fix for approval until an admin selects Approve again beside it under Changes › Automation › Policies (or on a baseline's page).

Anything else is drafted and sent for approval, with the reason, and the approvers are told. A change that is high-risk at the tenant, or cannot be fully undone, is approved on its own page with a tick that says you have read why. Each automatic fix is recorded in the approver's name with the policy, checked again against the tenant afterwards, reported to admins by email and in Teams or Slack, and can be rolled back from its page. Where several policies cover a check, a drafting policy wins over an automatic one.

Baselines that draft or fix

A baseline, under Compliance → Baselines, is the standard you hold tenants to. Besides showing who meets it, it can keep tenants to it. On its page, choose what it does when a tenant falls short:

• Report only: shows who meets it, who has slipped and who could not be checked. Nothing is drafted. Every plan, and where every baseline starts.
• Draft fixes: when a tenant in scope fails one of its checks that has an automated fix, one change is drafted, dry-run and sent for approval, the way any other draft is. Never a second change for the same check and tenant while one is open, and not again once someone dismisses it.
• Fix automatically: a standing approval, like an automatic policy, given in your name. Only fixes that can be undone and are not high-risk run on their own, after a clean dry run, within the baseline's size limit and the daily limits above. Everything else is drafted for approval, with the reason.

A baseline acts after each assessment, and as soon as a drift check or a re-check finds one of its checks newly failing. It never acts after a fix, a rollback or a finding marked resolved. Tenants with automation switched off get a simulation, under Automation → Activity.

Values. Some fixes take an answer: the MTA-STS mode, the partner domains people may share with, the office IP ranges, the label for groups, the owner for ownerless groups. A baseline can hold these, entered with the same inputs as on the finding, and checked the same way. Fixes whose targets someone must pick in each tenant (who stops being a Global Administrator, which groups are deleted) are never drafted by a baseline, and fixes that take a choice always wait for a person.

Accepted deviations. Where a tenant may differ, an admin accepts the deviation for that tenant and check, with the reason and a date it runs out, at most 12 months away. Until then the check counts as met with an exception, and nothing is drafted or run for it on that tenant, by the baseline or a policy. When it runs out, admins and whoever accepted it are told, and it counts again. A deviation belongs to the baseline: unlike an accepted risk, it does not take the finding out of the tenant's score.

Drafting from a baseline needs approved automation, and fixing automatically needs automatic fixes; values and report only work on every plan.

Containing accounts automatically

On a tenant's Changes › Automation page, an admin can turn on Automatic containment. When the security event check is sure an account has been taken over (impossible travel, MFA fatigue, or password spraying or guessing that got in), the account is contained straight away: sign-in blocked, every session revoked, and inbox rules that send mail outside, hide it or delete it turned off. MFA methods are left for a person to decide.

• List emergency access and service accounts to exclude; they still alert and can be contained by approval.
• A tenant that needs two approvers waits for a second admin to co-sign.
• Each containment is dry-run, recorded and reported to admins. Its inbox rules and sign-in can be put back: for the first 90 days, letting the account sign in again takes two different people, through Unblock sign-in on their People panel, so it is not rolled back by one person. Revoked sessions end and cannot be restored.
• Other alerts, such as a first sign-in from a new country or a Microsoft Defender alert that names an account, still offer containment for approval.
• On plans with automatic fixes, the security event check runs every 5 minutes rather than every 15 minutes, so containment starts sooner.

Pausing a tenant

Pausing also stops fixing and containing automatically. For a change freeze or an incident, select Pause automation on the tenant's Changes › Automation page, or Pause beside it under Changes › Automation › Tenants. While paused, nothing is drafted for the tenant and changes already approved wait without running. Resuming runs them. Pausing and resuming are recorded in the audit log.

When a change goes wrong

A change that did not do everything it should is listed under Needs attention, at the top of Changes and of the tenant's own Changes tab, worst first. It is shown on every plan. Each row has a pill and a line saying what happened:

• Rollback failed or Partly rolled back: the rollback did not finish, so some or all of the change is still in place.
• Got worse: in the check after the change, a check that reads what the change touched got worse, from passing to a warning or failing, or from a warning to failing. The change may be the cause. A fall in the Secure Score is shown as a note only, as other things move it too.
• Did not stick: read back afterwards, Microsoft shows something else on some of the objects.
• Partly done: some objects were changed and some were not, or it stopped before the rest.
• Failed: Microsoft refused it, so nothing was changed. Could not start: nothing was sent to the tenant.
• Approved · held: it was approved more than a day ago, but something stops it running, such as a missing permission, automation switched off or a paused tenant.
• Still failing: the change was made, but its check still fails 48 hours later, or once the days it waits for people to act are up. Not confirmed: it ran, but could not be read again to confirm it.
• Did not run: it was approved or scheduled, then expired after a re-check, or was cancelled by a move to a plan that makes no changes or because ConfigCheckup no longer makes it.

Open one to see What went wrong, first on its page: what happened, and what Microsoft said, grouped by kind, with Microsoft's own words and reference for support. Under Do it yourself in the tenant it lists the objects still to do and what each should end as (what was approved in the dry run), then, admin centre by admin centre, where to go, the steps for exactly those objects, how to check it took and the admin role you need. The admin-centre paths are as Microsoft names them at the time of this release. Where something may need putting back, Put it back by hand lists what the change's own rollback would write back, marked with the latest check of the rollback.

Where it can be undone, the steps come with the PowerShell for the same objects, built from the requests the change sends, with the commands to connect first. Read it before you run it, signed in as an admin of that tenant. It finds each object by its Microsoft id or sign-in name, never by its display name, and never prints a password. It is shown only to members who may raise that change, and never for a change that cannot be undone or needs two approvers, so a pasted script cannot get round those safeguards.

What you can do with it, by role:

• Try again (Admin, within 7 days of the run): checks the tenant first and only does what is left. Anything that changed goes back for approval.
• Raise it again (Consultant, or the role the change needs): starts a new change with a fresh dry run, which needs approval as before. Where another change for the same check is already open, you are pointed to it instead.
• Check the tenant now (Consultant): runs the dry run again to show what is still to do. It reads the tenant and changes nothing.
• I did it by hand (Consultant; Admin to say a change was put back): records what you did and checks the tenant afterwards. If the check still finds something to change, or the finding's check still fails, it opens again and you are told. A change ConfigCheckup cannot read is recorded on your word.
• Read the checks again (Consultant): for a check that got worse. A check that recovers clears it by itself.
• Close without fixing (Admin): with a reason of at least a sentence, kept in the audit log. The finding stays as the tenant shows it.
• Report a problem with this change (Consultant): for something ConfigCheckup cannot read, such as devices that stopped syncing. Owners and Admins are told straight away, and the change leads with checking the rollback.

While a check's last change at a tenant needs attention, an automation policy does not draft that check's fix there again until someone has dealt with it.

Home lists them under Needs you, and so does your morning email, for 30 days from when each began: up to three for a tenant, then one row for the tenant. My work › Today lists those you raised or approved and those at the tenants you look after; Owners and Admins also see any whose rollback did not finish, or after which a check got worse. The number on Changes in the menu counts them with the changes waiting for your approval.

Owners and Admins, whoever raised or approved the change, and whoever looks after the tenant are told in the bell, and by email as each person's notification settings say. Several at one tenant within ten minutes come as one notice. Nobody is told twice about the same thing, only again if it gets worse. A rollback that did not finish also goes to Teams or Slack when the workspace has connected one.

Rolling back

Reversible actions record the opposite change as they run. To undo one, open it under Changes and select Check the rollback (Admin role). This is a dry run of the rollback against the live tenant: it shows what each object is now and what the rollback would put back, which objects are already as they were, and which were changed by someone else after the change ran. Rolling back puts back what was there before the change, so it would overwrite those later changes: they are marked, and Roll back asks you to tick a box to overwrite them. A setting the rollback would write back that could not be read is treated the same way, as it may hide a later change: it is written back only once you tick the box. The rollback checks the tenant again as it starts. If anything changed since your check, or the tenant cannot be checked, it does not run and says so, so check it again. What it found is kept with the rollback, which is audited like the original. Actions that cannot be reversed, such as revoking sign-in sessions or deleting devices, say so before you approve them. A containment, or the incident response runbook, that blocked sign-in in the last 90 days is not rolled back this way: letting that account in again takes two different people, through Unblock sign-in.

Straight after taking someone out of a group or a mailbox, the person who did it can select Undo in the result, for 30 minutes, unless the mailbox belongs to an admin. The same goes for a change that added something, such as a licence, a group membership, mailbox access or a group owner: the person who made it can undo it for 30 minutes, with no approver, and an Admin or Owner can at any time; nobody else can. Undo puts back exactly what the change took or gave, through its own rollback, and never overwrites anything changed since: where something has, it does not run and says so. The audit log records it as an undo. A change that made an account, a group, a guest or a mailbox is never undone this way, nor is one someone approved: roll it back from its page.

Rolling back a fix across tenants

On a fix across tenants, Roll back everywhere (Admin role) rolls each tenant's change back as its own rollback. Each is checked for its own change (your role, whether it can be undone, and the tenant's permissions) and against its own tenant first. Changes the fix made that have not run yet are cancelled, so nothing more of the fix runs, and a change still running is rolled back once it finishes. A change that was already open at a tenant before the fix is that tenant's own, and is left alone: roll it back from its own page if it should go. A tenant where something changed after the fix ran is left as it is, unless you tick the box to overwrite later changes. Tenants can end differently: each row says whether it rolled back, only partly, failed, or was left, and why. A rollback that stopped before it could say how it ended shows as failed within a few minutes. Nothing is retried on its own. Select it again to try the tenants that did not roll back, or roll one back from its own change's page.

What can be automated

ConfigCheckup can make 88 kinds of change. 74 of them can be rolled back, and 54 may run on their own under a policy; the rest are always approved by a person. Every kind, with whether it can be undone and whether it always needs two people, is listed on every kind of change.

Questions about what automation can touch? See data protection or the FAQ.