When I first started learning Conditional Access in Microsoft Entra ID, I quickly realized that it
wasn't just another administrative setting. Conditional Access has the ability to control who can access
resources, from where they can access them, and what conditions must be met before access is
granted.
That realization was both exciting and a little intimidating.
Unlike many settings in Microsoft 365, a mistake in Conditional Access can have immediate consequences.
A poorly configured policy can prevent legitimate users from accessing applications, services, or even
the tenant itself. Since this was a lab environment, I wanted to experiment and learn, but I also wanted
to avoid creating problems that I wasn't prepared to solve.
As I began exploring Conditional Access, I also learned about the difference between Security Defaults
and Conditional Access policies. Security Defaults provide Microsoft's recommended baseline protections
and are designed to improve security with minimal administrative effort. Conditional Access, on the
other hand, offers significantly more flexibility and control over who is affected, when policies apply,
and what conditions must be met.
That flexibility is powerful, but it also means there is more opportunity to make mistakes.
While creating my first Conditional Access policies, I discovered a feature called Report-only mode. At
first it didn't seem particularly exciting. The policy wasn't enforcing anything and users wouldn't
experience any changes.
Then I realized how valuable it really was.
Report-only mode allowed me to build and test policies without actually enforcing them. I could select
users, configure conditions, and define access controls while safely observing what would have happened
if the policy had been active.
That opened the door to learning without fear of locking myself out.
I created several test policies and began experimenting with included users, excluded users, and
different assignment scenarios. Instead of guessing how the policies would behave, I could verify the
results through Microsoft Entra sign-in logs.
The sign-in logs quickly became one of the most valuable tools in the entire learning process.
Each authentication attempt showed whether a Conditional Access policy would have applied, which users
were affected, and how the policy evaluation process reached its decision. For the first time, I could
watch Conditional Access working behind the scenes without risking disruption to the
environment.
One of the biggest lessons I learned was that creating a policy and understanding a policy are two very
different things. It is easy to select users and enable controls. It is much harder to predict every
outcome before users begin signing in and interacting with those policies.
Report-only mode gave me an opportunity to test my assumptions before they became problems.
Looking back, the most valuable lesson wasn't about multifactor authentication, user assignments, or
policy settings.
The most valuable lesson was simply to test before enforcing.
Report-only mode allowed me to learn Conditional Access safely. It helped me understand how policies
were evaluated, verify my configurations, and gain confidence before enabling anything that could impact
users.
For anyone beginning their Conditional Access journey, my recommendation is straightforward.
Don't rush to activate new policies.
Use Report-only mode, review the sign-in logs, understand exactly what the policy is doing, and make
adjustments until you're confident in the results.
Getting locked out may be a memorable learning experience, but learning without getting locked out is
even better. 🐦🐦