0.4 Before You Change Anything

Introduction

Every build in this course changes something, and every change can go wrong: a policy that blocks the wrong people, a role left assigned after the task, an exclusion nobody remembers adding, a deletion that cannot be undone.

In a lab the cost is an afternoon; in a tenant other people use it can be an outage or a gap an attacker walks through. The habits that prevent both are the same, and the lab is the place to make them automatic.

This lesson sets the rules for changing a tenant: why changes need rules, the range's own month of changes, roles just in time, report-only first, a change record for every setting, a rollback for every change, the ways back in, and what never to do in a tenant other people use. Microsoft's statements here were checked against Microsoft Learn, 8 November 2026.

A security configuration change has three ways to go wrong. It can do something other than intended: a policy that blocks more than it should, or less. It can be made by the wrong person, or with more privilege than the task needed. And it can be impossible to undo, because nobody wrote down what it replaced. Each of those has a matching habit:

Put in order, the habits make one sequence that every change in the course follows, from the first build onward:

Plan first: what changes, why, and how to undo it. Activate the role the change needs, for the time it needs, rather than holding it permanently.

Where the change can be evaluated before it is enforced, as a Conditional Access policy can, evaluate it and read the results. Enforce it once the results say it does what was intended. Then record it: the change, the evidence that it worked, and the rollback.

The sequence costs minutes and pays for itself the first time a change goes wrong, because the plan says what to undo and the record says how. It also makes changes reviewable. A change with a record can be checked by someone else; a change without one can only be rediscovered from the audit log, by someone who has to guess at the reason.

The lab is where the sequence becomes habit. Nothing you break there affects anyone, which makes it tempting to skip the steps; it is also exactly why it is the right place to practice them. A habit formed on changes that do not matter is the one you will have on the changes that do.

Every build card in the course follows the sequence. Its prerequisites name the role; its steps include the evaluation where there is one; its checks are the evidence; its undo line is the rollback. Reading the build card before starting is the plan.

Take every change through plan, role, evaluation, enforcement and record, starting with the first build in the lab.

The range holds a month of an organization's administrators changing their tenant, and it shows the habits this lesson is about, good and bad. Every Conditional Access and role change on the range, by kind:

AuditLogs
| where OperationName has "conditional access" or OperationName has "role"
| summarize Changes = count(), FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated) by OperationName
| order by Changes desc

Role changes dominate. There are 57 PIM activations, each one an administrator making an eligible role active for a task, and a matching number of role additions and removals as those activations start and end. That is the pattern of just-in-time access working: roles held when needed and dropped afterward, with every use recorded.

One line breaks the pattern: a role assignment made outside PIM, permanently, on 12 March. A permanent assignment is a standing privilege, held whether or not it is used, and the kind of assignment an attacker who compromises the account inherits immediately. It is one line among more than a hundred role changes, and it is the one an audit should find first.

The Conditional Access changes are fewer and more varied: policies added, updated and deleted, by two administrators over the month. Each one changed who is challenged or blocked at sign-in, so each one deserves the full sequence. The next sections read them one at a time.

The same query in your own tenant shows your administrators' habits. A high count of PIM activations with few permanent assignments is a tenant where just-in-time access is the norm. A tenant where role additions appear without matching activations is one where roles are being handed out directly, which is the first thing to fix.

Reading the month this way takes one query and a few minutes, and it tells you more about how a tenant is run than any document describing its change process.

Read your tenant's role and policy changes as a record of its administrators' habits, and look first for the permanent assignment among the activations.

Privileged Identity Management is how a tenant gives people the roles they need without leaving those roles standing:

Microsoft's description is precise about what PIM changes and what it does not.

An eligible assignment grants exactly the same access as an active one; the difference is that an eligible user must activate the role first, with multifactor authentication, a justification and, where it is configured, an approval. Each activation is time-bound, sends a notification and lands in the audit history. Between activations, the account holds nothing an attacker could use.

For the lab, the rule is simple: your daily account holds no standing roles, and is eligible for each role the course's builds need. A build card names the role; you activate it, do the build, and let it expire:

Microsoft's page notes that PIM needs licenses, which the E5 trial covers through Entra ID P2. It also notes one protection worth knowing: PIM will not let you remove the last active Global Administrator or Privileged Role Administrator assignment, which stops a lab from locking itself out of role management entirely.

The habit matters beyond security. A build done with only the role it needs shows you what that role can and cannot do, which is the knowledge you need to give the same role to someone else in a real SOC. A build done as Global Administrator teaches nothing about roles, because everything works.

On the range, every one of the 57 activations is a line in the audit log with an account, a role and a time. The one permanent assignment has no activation behind it, and that absence is exactly what makes it stand out.

Activation also leaves a trail you can use: the audit entry for each activation, with its reason, is the first line of the change record for whatever the build changed.

Make your daily account eligible for each role the course needs, activate one per build, and let each activation expire.

Conditional Access policies have a mode built for exactly the sequence above: report-only, in which the policy is evaluated at every sign-in and its result logged, but nothing is enforced:

The range's five Conditional Access changes, each with the property it changed and the values before and after:

AuditLogs
| where OperationName has "conditional access"
| extend Target = parse_json(TargetResources)[0]
| extend Policy = tostring(Target.displayName),
    Property = tostring(Target.modifiedProperties[0].displayName),
    Before = tostring(Target.modifiedProperties[0].oldValue),
    After = tostring(Target.modifiedProperties[0].newValue),
    Actor = tostring(parse_json(InitiatedBy).user.userPrincipalName)
| project TimeGenerated, OperationName, Policy, Property, Before, After, Actor
| order by TimeGenerated asc

Two changes moved a policy from disabled to report-only, which is the start of the sequence done right. One added a policy, Require MFA for guest access, straight to enabled, at 08:36 on 11 March, with no report-only period in the record. One changed Require MFA for all users by adding legacy-print-001 to its excluded applications, on 05 March. One deleted a report-only pilot.

Each of those deserves a question. The policy enabled straight to On may have been right, and nothing in the record shows what it would have done before it did it; a report-only week would have.

The exclusion widened a gap in the tenant's most important policy, and the record shows who added it and when, and nothing about why or until when. The deletion removed a policy that was only reporting, which is harmless, and also removed the record of what it was testing.

Microsoft's guidance covers the second case directly. To change a policy that is already enforced, create a report-only copy with the proposed change, compare its results with the original, then apply the change and delete the copy. The exclusion would then have had a week of results showing exactly which sign-ins it let through without MFA.

Report-only has limits Microsoft names: policies scoped to user actions cannot be fully evaluated, and a policy requiring a compliant device can prompt mobile and macOS users for a certificate even in report-only. Neither affects the course's builds.

Take every new or changed Conditional Access policy through report-only, read its results on real sign-ins, and change an enforced policy through a report-only copy.

A change record answers the questions someone will ask later: what changed, why, who did it, how we know it worked, and how to undo it:

Most of it is already in the audit log. The what, the who and the when are there for every directory change, as the range's Conditional Access changes show: the policy, the property, the old and new values, the account and the time.

What the audit log cannot hold is the why, the evidence that the change did what was intended, and the rollback. Those three lines are the change record's real content.

The why connects the change to its reason: the build card, the finding, the incident. An exclusion with a recorded reason can be reviewed against that reason; one without can only be guessed at, and an exclusion nobody can explain is usually left in place because removing it feels riskier than keeping it.

The evidence is the result that shows the change worked: the sign-in where the policy applied, the alert the setting raised, the query that returned what it should. It is what a build card's checks produce, and it is what separates a change that was made from one that was made and verified.

The rollback is written before the change, because after the change it is too easy to write what you think the old value was rather than what it was. For a policy, the old value is the exported policy; for a setting, the value from the portal or PowerShell before you touched it.

In the lab, the change record lives in your build evidence. In a real tenant, it lives in the change process, and the habit is the same.

Write a change record for every setting you change, with the why, the evidence and the rollback that the audit log cannot hold.

Every kind of change has a way back, and most are simple when written down in advance:

A new Conditional Access policy is the easiest: turn it off, and if it stayed in report-only, the audit log shows it never enforced anything. A change to an enforced policy is restored from the report-only copy Microsoft recommends, or from the exported original.

A role assignment is removed, and an eligible one expires on its own end date. A protection setting is set back to the value the change record holds. A containment action has a documented reverse: a device released from isolation, an account re-enabled, a sender unblocked.

The exception is deletion. A deleted policy, a deleted rule or a deleted workspace often cannot be brought back, and a deleted record cannot be queried again.

The range's deleted pilot policy is gone from the tenant; what remains is one audit line with its name and its last state. The rollback for a deletion is an export made before it, and where there is no export, the safer choice is usually not to delete.

The test of a rollback is whether someone else could follow it from the record alone. "Revert the policy" fails that test; "set Require MFA for all users' excluded applications back to the list in the export taken before the change" passes it. The build for this lesson asks for exactly that: a rollback followed by someone other than the person who wrote it.

Rollbacks are also part of the response work later in the course. Containment actions are changes, made under pressure, and each one has to be reversible when the incident ends. The habit of writing the way back before acting is what makes a fast containment safe.

Write each change's rollback before making it, export anything before deleting it, and test that someone else could follow the rollback from the record.

The course's builds include policies that block sign-in, written by someone learning to write them. Before any of those exist, the lab needs a way back in that no policy can block:

Microsoft recommends two permanently assigned, cloud-only emergency access accounts holding Global Administrator, not tied to any one person. In the lab, both are yours; what matters is that they are excluded from every Conditional Access policy the builds create, that their credentials are somewhere you can reach when your daily account cannot sign in, and that you have signed in with each once and seen the sign-in in the log.

The exclusion is the part most often missed. A policy written to require MFA for all users, with no exclusions, includes the emergency accounts, and a mistake in that policy locks them out as well. Every Conditional Access build in the course excludes them, and every report-only result should show them as Not applied.

These accounts are also the one place a permanent, standing Global Administrator assignment is correct. They exist for the moment when nothing else works, including PIM. That makes them a target, so any sign-in by them is worth looking at, in the lab as in production.

The range has a version of this lesson in it. Its organization's policies carry exclusions, and the course reads them in the identity module: which accounts and applications are excluded, who added each, and whether each still needs to be. An emergency access exclusion is the one that should always be there; most others should have an owner and a date.

Test them again after any build that adds a blocking policy, because the exclusion is the part a new policy is most likely to have missed.

Create and test two emergency access accounts before writing any blocking policy, and exclude them from every Conditional Access policy the course builds.

Some habits are acceptable in a lab and never acceptable in a tenant other people depend on. Each of them appears in the range's month:

A policy enabled straight to On is there: Require MFA for guest access, with no report-only period in the record. A standing role is there: the one permanent assignment made outside PIM.

An exclusion with no owner or review date is there: the application added to the exclusions of Require MFA for all users. A deletion with no export is there: the pilot policy, gone. None of these needed to be a mistake, and each became a risk because nothing recorded why it was safe.

The fifth line is the one that holds the others together. A change process exists so that changes are planned, reviewed and recorded, and the most dangerous changes are the small urgent ones made outside it: a quick exclusion to unblock an executive, a role granted for an afternoon and never removed.

In the lab, there is no process to go around, so the habit to practice is behaving as if there were.

That is the reason the lab follows the same rules as production. A lab where anything goes trains anything-goes habits, and those habits come with you. A lab where every change has a role, an evaluation, a record and a rollback trains the habits a real SOC expects from the first day.

The range's administrators were not careless; most of their month is good practice. The five exceptions are what an audit looks for, and the course's audits ask you to find exactly these patterns in other teams' configurations.

When you inherit a tenant, the same five checks make a quick first audit: one query each, and the results tell you where the tenant's change discipline has slipped.

Practice in the lab exactly the change discipline you would follow in production, and look for these five patterns first in any tenant you inherit.

The build sets up the roles, the ways back in and the change record every later build uses.

Every change in the course goes through the same steps: plan it, activate the role it needs, evaluate it where that is possible, enforce it once the results are read, and record it with its evidence and rollback.

On the range, 57 PIM activations show just-in-time access working, and one permanent assignment outside PIM, one policy enabled straight to On, one unexplained exclusion and one deletion show what the steps prevent.

Take every Conditional Access change through report-only, write each rollback before the change, and set up two tested emergency access accounts before any blocking policy. If you do one thing this week, make your daily account eligible rather than active for every role it holds.

Resources

Microsoft revises these pages; where a page and this lesson disagree, the page is newer.

• Microsoft Learn: What is Privileged Identity Management? (checked 8 November 2026)
• Microsoft Learn: Conditional Access report-only mode (checked 8 November 2026)
• Microsoft Learn: Create a new tenant in Microsoft Entra ID (checked 8 November 2026)