Your Conditional Access Policy Has Trust Issues: We Need To Talk

1
00:00:00,000 –> 00:00:01,680
It’s not misbehaving, it’s overwhelmed.

2
00:00:01,680 –> 00:00:03,560
Your conditional access is trying to protect you

3
00:00:03,560 –> 00:00:06,600
while juggling mixed messages and unresolved exceptions.

4
00:00:06,600 –> 00:00:08,280
It’s been asked to trust without boundaries.

5
00:00:08,280 –> 00:00:09,080
Here’s the plan.

6
00:00:09,080 –> 00:00:11,720
We’ll diagnose three trust wounds, overbroad exclusions,

7
00:00:11,720 –> 00:00:13,960
device compliance gaps and token theft paths,

8
00:00:13,960 –> 00:00:16,360
and give you a calming baseline, a safe test plan,

9
00:00:16,360 –> 00:00:17,680
and monitoring alerts.

10
00:00:17,680 –> 00:00:19,360
If you’re running a law by default,

11
00:00:19,360 –> 00:00:22,400
you’re leaking trust and inviting silent bypasses.

12
00:00:22,400 –> 00:00:23,920
There’s a mistake that locks out everyone

13
00:00:23,920 –> 00:00:26,480
and one that leaves attackers invisible, both are fixable.

14
00:00:26,480 –> 00:00:28,160
Let’s help it set healthy boundaries

15
00:00:28,160 –> 00:00:31,840
so it can find its rhythm again, starting with exclusions.

16
00:00:31,840 –> 00:00:34,440
Diagnosed trust wound number one, overbroad exclusions.

17
00:00:34,440 –> 00:00:35,880
Exclusions feel kind.

18
00:00:35,880 –> 00:00:38,160
You didn’t want to stress the system or the people in it

19
00:00:38,160 –> 00:00:41,840
so you carved out break glass VIPs and that partner domain,

20
00:00:41,840 –> 00:00:43,120
but boundaries drift.

21
00:00:43,120 –> 00:00:45,160
The exceptions harden and conditional access

22
00:00:45,160 –> 00:00:46,320
starts doubting itself.

23
00:00:46,320 –> 00:00:48,840
It’s not misbehaving, it’s living with an ever-growing list

24
00:00:48,840 –> 00:00:51,880
of not you, not now, and that invites bypasses attackers

25
00:00:51,880 –> 00:00:52,720
a door.

26
00:00:52,720 –> 00:00:54,920
The thing most people miss is that exclusions

27
00:00:54,920 –> 00:00:57,000
are invisible in day-to-day flow.

28
00:00:57,000 –> 00:00:58,040
You won’t see a banner that says

29
00:00:58,040 –> 00:01:00,240
we skipped protection for the CFO.

30
00:01:00,240 –> 00:01:02,560
You’ll just see not applied in a log and that’s it.

31
00:01:02,560 –> 00:01:03,840
So we start by mapping scope.

32
00:01:03,840 –> 00:01:06,880
List every exclusion across users, groups, applications,

33
00:01:06,880 –> 00:01:09,360
locations, and authentication contexts.

34
00:01:09,360 –> 00:01:11,320
Nested groups are the quiet leakers here.

35
00:01:11,320 –> 00:01:14,400
What looked like one exception is actually five layers deep,

36
00:01:14,400 –> 00:01:16,280
including contractors, test accounts,

37
00:01:16,280 –> 00:01:18,360
and legacy sync artifacts.

38
00:01:18,360 –> 00:01:21,240
This clicked for me when I pulled a tenants, sign in logs,

39
00:01:21,240 –> 00:01:23,880
and filtered for conditional access, not applied.

40
00:01:23,880 –> 00:01:25,320
The pattern wasn’t random.

41
00:01:25,320 –> 00:01:27,480
Most bypasses sourced from two places.

42
00:01:27,480 –> 00:01:29,800
A VIP group attached to three policies

43
00:01:29,800 –> 00:01:32,720
and a named location that had grown from one corporate CIDR

44
00:01:32,720 –> 00:01:35,880
to anywhere our vendor might be.

45
00:01:35,880 –> 00:01:37,080
It wasn’t malice.

46
00:01:37,080 –> 00:01:38,160
It was comfort.

47
00:01:38,160 –> 00:01:41,760
The policy was trying to keep the piece by saying yes too often.

48
00:01:41,760 –> 00:01:42,840
Here’s the better pattern.

49
00:01:42,840 –> 00:01:47,680
Move from exclude VIPs to include all and authorize exceptions

50
00:01:47,680 –> 00:01:49,840
through time-bound authentication context.

51
00:01:49,840 –> 00:01:51,680
That shift sets healthy boundaries.

52
00:01:51,680 –> 00:01:54,920
You keep policies broad and inclusive, all users, all cloud apps,

53
00:01:54,920 –> 00:01:57,280
and when someone truly needs to step around the control,

54
00:01:57,280 –> 00:01:59,280
they request the emergency context, which

55
00:01:59,280 –> 00:02:02,080
has approval of one hour lifetime and audit trails.

56
00:02:02,080 –> 00:02:04,760
The trust becomes explicit, visible, and short-lived.

57
00:02:04,760 –> 00:02:06,760
Let me show you exactly how to see your leaks.

58
00:02:06,760 –> 00:02:09,720
In enter a sign-in logs, add columns for conditional access,

59
00:02:09,720 –> 00:02:12,040
policy name, result, and details.

60
00:02:12,040 –> 00:02:13,280
Filter result for not applied.

61
00:02:13,280 –> 00:02:16,400
Now slice by user, then by app, and finally by location.

62
00:02:16,400 –> 00:02:18,240
You’re looking for clusters not one-offs,

63
00:02:18,240 –> 00:02:20,520
the big red flags, permanent exclusions

64
00:02:20,520 –> 00:02:23,960
for executives or service accounts, entire federated domains

65
00:02:23,960 –> 00:02:25,960
are hard to save and named locations that

66
00:02:25,960 –> 00:02:28,680
mix trusted with convenience networks.

67
00:02:28,680 –> 00:02:30,800
If you remember nothing else, remember this.

68
00:02:30,800 –> 00:02:33,440
A permanent exclusion is a permanent invitation.

69
00:02:33,440 –> 00:02:36,240
What should the policy logic feel like before and after?

70
00:02:36,240 –> 00:02:37,200
Before.

71
00:02:37,200 –> 00:02:40,280
Multiple policies with include groups and broad exclude lists,

72
00:02:40,280 –> 00:02:43,840
VIPs, breakglas, certain apps, and a safe location.

73
00:02:43,840 –> 00:02:46,840
The engine spends energy deciding who not to protect.

74
00:02:46,840 –> 00:02:49,720
After fewer inclusive policies with no user or location

75
00:02:49,720 –> 00:02:53,120
exclusions, exceptions root via a specific authentication

76
00:02:53,120 –> 00:02:55,480
context presented only when an approver grants it

77
00:02:55,480 –> 00:02:56,640
and it expires quickly.

78
00:02:56,640 –> 00:02:57,560
The engine can breathe.

79
00:02:57,560 –> 00:03:00,360
It protects first, then allows controlled, visible relief

80
00:03:00,360 –> 00:03:00,960
when needed.

81
00:03:00,960 –> 00:03:02,760
Here’s a quick win you can do today.

82
00:03:02,760 –> 00:03:05,840
Create an authentication context called emergency bypass.

83
00:03:05,840 –> 00:03:09,080
Set it with grant controls that still require MFA and device

84
00:03:09,080 –> 00:03:12,200
risk checks and cap session to one hour, add an approval

85
00:03:12,200 –> 00:03:14,320
workflow outside the policy, change ticket,

86
00:03:14,320 –> 00:03:16,960
or documented approver, and log its use weekly.

87
00:03:16,960 –> 00:03:20,040
Now replace hard-coded exclusions in your existing policies

88
00:03:20,040 –> 00:03:22,720
with require authentication context.

89
00:03:22,720 –> 00:03:24,520
Emergency bypass.

90
00:03:24,520 –> 00:03:25,880
You haven’t taken away safety.

91
00:03:25,880 –> 00:03:27,120
You’ve given it a safer shape.

92
00:03:27,120 –> 00:03:28,600
Now here’s where most people mess up.

93
00:03:28,600 –> 00:03:30,400
They exclude an entire partner domain

94
00:03:30,400 –> 00:03:33,000
because one app misbehaved during a rollout,

95
00:03:33,000 –> 00:03:36,920
or they mark a cloud proxy IP range as trusted, forgetting

96
00:03:36,920 –> 00:03:39,400
that attackers can originate from the same provider.

97
00:03:39,400 –> 00:03:42,200
Or they mix excluded locations with named locations.

98
00:03:42,200 –> 00:03:44,520
Assuming the union is safer, it’s not.

99
00:03:44,520 –> 00:03:46,800
It becomes a fuzzy map your policy doesn’t understand.

100
00:03:46,800 –> 00:03:49,720
With clearer lines, CA can find its rhythm again.

101
00:03:49,720 –> 00:03:52,120
Common mistake number two is forgetting service principles

102
00:03:52,120 –> 00:03:53,760
and workload identities.

103
00:03:53,760 –> 00:03:56,400
If your policies only target users and groups,

104
00:03:56,400 –> 00:03:59,160
your automation can glide under the radar.

105
00:03:59,160 –> 00:04:02,240
Instead, use dedicated policies for service principles

106
00:04:02,240 –> 00:04:05,200
and workload identities and never rely on exclusions

107
00:04:05,200 –> 00:04:07,240
to fix automation friction.

108
00:04:07,240 –> 00:04:09,520
Help it heal by aligning scopes, users, guests,

109
00:04:09,520 –> 00:04:11,480
and identities each get coverage.

110
00:04:11,480 –> 00:04:12,520
A micro story.

111
00:04:12,520 –> 00:04:14,560
Last week, a team removed a VIP exclusion

112
00:04:14,560 –> 00:04:15,960
that had lived for two years.

113
00:04:15,960 –> 00:04:17,640
They replaced it with emergency bypass

114
00:04:17,640 –> 00:04:20,560
and scheduled a weekly review of not applied sign-ins.

115
00:04:20,560 –> 00:04:23,080
Within two days, they found a legacy sync account

116
00:04:23,080 –> 00:04:25,720
silently logging in from an unmanaged network.

117
00:04:25,720 –> 00:04:27,440
No MFA, no device checks.

118
00:04:27,440 –> 00:04:28,400
It wasn’t evil.

119
00:04:28,400 –> 00:04:30,560
It was a forgotten comfort blanket.

120
00:04:30,560 –> 00:04:33,040
And once it was named, the fix was simple,

121
00:04:33,040 –> 00:04:35,080
assigned to a managed identity pattern

122
00:04:35,080 –> 00:04:36,120
and bring it under policy.

123
00:04:36,120 –> 00:04:37,360
And the reason this works is simple,

124
00:04:37,360 –> 00:04:39,520
inclusive scopes reduce cognitive load.

125
00:04:39,520 –> 00:04:42,680
Authentication context replaces permanence with intention

126
00:04:42,680 –> 00:04:45,200
and logs become meaningful because every not applied

127
00:04:45,200 –> 00:04:46,800
means something actionable.

128
00:04:46,800 –> 00:04:49,120
Your conditional access isn’t trying to be difficult.

129
00:04:49,120 –> 00:04:52,000
It just needs you to stop asking it to ignore its own rules.

130
00:04:52,000 –> 00:04:53,320
With gentler, firmer boundaries,

131
00:04:53,320 –> 00:04:56,880
it can protect everyone, equally, predictably, audibly.

132
00:04:56,880 –> 00:04:58,480
Once exclusion stop leaking,

133
00:04:58,480 –> 00:05:00,960
the device boundary needs care next.

134
00:05:00,960 –> 00:05:03,960
Diagnosed trust, wound number two, device compliance gaps.

135
00:05:03,960 –> 00:05:05,440
Your device boundary is tired.

136
00:05:05,440 –> 00:05:06,800
It’s been asked to trust badges.

137
00:05:06,800 –> 00:05:09,320
It can’t verify and signals that arrive late.

138
00:05:09,320 –> 00:05:11,600
Require a compliant device sound soothing,

139
00:05:11,600 –> 00:05:14,280
but without clarity, it swings between over permissive

140
00:05:14,280 –> 00:05:15,120
and overprotective.

141
00:05:15,120 –> 00:05:17,360
And that’s why people get blocked on a clean laptop

142
00:05:17,360 –> 00:05:19,320
while an unmanaged tablet slips through,

143
00:05:19,320 –> 00:05:21,400
it’s not misbehaving, it’s confused.

144
00:05:21,400 –> 00:05:22,240
Why does this matter?

145
00:05:22,240 –> 00:05:24,800
Because device state is identity’s closest friend.

146
00:05:24,800 –> 00:05:27,880
If the state is wrong or missing, your policy guesses.

147
00:05:27,880 –> 00:05:31,080
Gases create silent allowances or mass blocks.

148
00:05:31,080 –> 00:05:34,160
When the device story is clear, conditional access relaxes.

149
00:05:34,160 –> 00:05:36,320
It can give easy paths to healthy devices

150
00:05:36,320 –> 00:05:38,280
and set firmer boundaries everywhere else.

151
00:05:38,280 –> 00:05:42,120
The thing most people miss is that registered is not compliant.

152
00:05:42,120 –> 00:05:45,240
Registered just means the device introduced itself.

153
00:05:45,240 –> 00:05:47,320
Compliant means it met your health rules

154
00:05:47,320 –> 00:05:49,400
in Intune and brought proof today.

155
00:05:49,400 –> 00:05:52,000
Hybrid Azure AD Joint is about identity alignment

156
00:05:52,000 –> 00:05:53,040
with your domain.

157
00:05:53,040 –> 00:05:54,480
They are different kinds of trust.

158
00:05:54,480 –> 00:05:56,320
If you remember nothing else, remember this.

159
00:05:56,320 –> 00:05:58,400
Treat each tier as a distinct promise.

160
00:05:58,400 –> 00:05:59,600
Here’s the model that clicks.

161
00:05:59,600 –> 00:06:01,960
Define four tiers in plain language.

162
00:06:01,960 –> 00:06:07,200
Compliant, Intune evaluates and the device meets your policies.

163
00:06:07,200 –> 00:06:10,120
Hybrid Azure AD Joint Domain Relationship Verified

164
00:06:10,120 –> 00:06:11,720
Device Identity Anchored.

165
00:06:11,720 –> 00:06:14,600
Azure AD Joint Cloud Managed Corporate Device.

166
00:06:14,600 –> 00:06:18,600
Registered BYOD, Personal or Light Touch Enrollment.

167
00:06:18,600 –> 00:06:21,880
Now let’s help it set healthy boundaries with policy design.

168
00:06:21,880 –> 00:06:23,640
Split decisions by device state

169
00:06:23,640 –> 00:06:26,160
rather than hinging everything on one control.

170
00:06:26,160 –> 00:06:29,160
Use filters for devices to target platform or join type

171
00:06:29,160 –> 00:06:30,960
and pair with authentication strengths.

172
00:06:30,960 –> 00:06:33,840
So strong credentials backstop weaker device states.

173
00:06:33,840 –> 00:06:37,360
Don’t ask a single toggle to carry your whole zero trust posture.

174
00:06:37,360 –> 00:06:39,280
What does the better pattern look like?

175
00:06:39,280 –> 00:06:41,760
For productive low friction access on compliant

176
00:06:41,760 –> 00:06:44,920
or Azure AD Joint devices allow with MFA

177
00:06:44,920 –> 00:06:47,200
and apply session controls like sign-in frequency

178
00:06:47,200 –> 00:06:49,280
and continuous access evaluation.

179
00:06:49,280 –> 00:06:52,400
For registered devices, step up with Fishing Resistant MFA

180
00:06:52,400 –> 00:06:55,160
and Limit Data Exposure with App Enforced Restrictions

181
00:06:55,160 –> 00:06:56,640
and Conditional App Control.

182
00:06:56,640 –> 00:07:00,000
For unknown devices, require either a compliant posture

183
00:07:00,000 –> 00:07:01,480
or a high authentication strength

184
00:07:01,480 –> 00:07:03,320
before granting anything sensitive.

185
00:07:03,320 –> 00:07:05,480
And for admin portals, demand both a compliant

186
00:07:05,480 –> 00:07:07,880
or hybrid device and Fishing Resistant credentials.

187
00:07:07,880 –> 00:07:08,800
No device, no keys.

188
00:07:08,800 –> 00:07:11,120
Let me show you exactly how to get signal clarity.

189
00:07:11,120 –> 00:07:13,360
In sign-in logs, add device info columns,

190
00:07:13,360 –> 00:07:16,440
join type, compliant, trust type and operating system.

191
00:07:16,440 –> 00:07:19,840
Add conditional access columns for result and policy details,

192
00:07:19,840 –> 00:07:21,920
filter failures with ground control required,

193
00:07:21,920 –> 00:07:24,920
compliant device and compare against device info.

194
00:07:24,920 –> 00:07:28,160
You’re looking for drift, devices that claim Azure AD joined

195
00:07:28,160 –> 00:07:30,560
but aren’t compliant or registered devices

196
00:07:30,560 –> 00:07:32,560
that succeeded because no fallback existed.

197
00:07:32,560 –> 00:07:35,080
Then flip the lens, filter successes where device

198
00:07:35,080 –> 00:07:38,120
is not compliant and see which policies allow it and why,

199
00:07:38,120 –> 00:07:39,600
a quick win you can do today.

200
00:07:39,600 –> 00:07:41,240
Create a fallback policy.

201
00:07:41,240 –> 00:07:43,800
Scope it to all users and all cloud apps.

202
00:07:43,800 –> 00:07:46,320
Exclude only your emergency access accounts.

203
00:07:46,320 –> 00:07:49,000
Target devices where compliant equals falls

204
00:07:49,000 –> 00:07:51,560
or join type equals registered.

205
00:07:51,560 –> 00:07:54,160
Grant access if the user satisfies a Fishing Resistant

206
00:07:54,160 –> 00:07:55,600
Authentication Strength.

207
00:07:55,600 –> 00:07:58,000
Add session controls to reduce data persistence,

208
00:07:58,000 –> 00:07:59,720
disable persistent browser sessions

209
00:07:59,720 –> 00:08:01,520
and enforce sign-in frequency.

210
00:08:01,520 –> 00:08:03,520
This turns a hard block into a safe step-up

211
00:08:03,520 –> 00:08:06,280
and removes the urge to add risky exclusions.

212
00:08:06,280 –> 00:08:07,800
Now here’s where most people mess up.

213
00:08:07,800 –> 00:08:10,960
They assume registered equals corporate or it doesn’t

214
00:08:10,960 –> 00:08:13,200
or they stamp require compliant device on everything

215
00:08:13,200 –> 00:08:15,120
then watch VIP travel laptops fail

216
00:08:15,120 –> 00:08:17,360
because the compliance signal is stale

217
00:08:17,360 –> 00:08:18,960
or they ignore sign-in frequency.

218
00:08:18,960 –> 00:08:21,160
Letting a compliant check at 9 a.m.

219
00:08:21,160 –> 00:08:22,520
Bless a browser until next week.

220
00:08:22,520 –> 00:08:24,760
The boundary blurs attack us love blurred boundaries.

221
00:08:24,760 –> 00:08:26,240
The reason this works is simple.

222
00:08:26,240 –> 00:08:29,160
With clearer tears, CA doesn’t have to overreact.

223
00:08:29,160 –> 00:08:32,040
It can greet a compliant device with less friction,

224
00:08:32,040 –> 00:08:34,520
ask a registered device to bring stronger proof

225
00:08:34,520 –> 00:08:36,360
and keep unknown devices at arms length.

226
00:08:36,360 –> 00:08:39,000
It’s not rejection, it’s healthy distance.

227
00:08:39,000 –> 00:08:40,920
Let’s anchor with a micro story.

228
00:08:40,920 –> 00:08:42,960
A team saw random admin portal access

229
00:08:42,960 –> 00:08:44,480
from registered MacBooks.

230
00:08:44,480 –> 00:08:46,920
No policy blocked it because require compliant

231
00:08:46,920 –> 00:08:48,520
wasn’t in scope for that app.

232
00:08:48,520 –> 00:08:50,760
They added the fallback with Fishing Resistant Strength

233
00:08:50,760 –> 00:08:53,320
and those same attempts now prompt for a strong key.

234
00:08:53,320 –> 00:08:55,320
Admins move to manage devices within a week

235
00:08:55,320 –> 00:08:57,600
because the boundary was calm and consistent.

236
00:08:57,600 –> 00:08:59,240
Once your device signals feel steady,

237
00:08:59,240 –> 00:09:01,120
we need to close the gap attackers use

238
00:09:01,120 –> 00:09:02,120
after they steal tokens.

239
00:09:02,120 –> 00:09:03,120
That’s next.

240
00:09:03,120 –> 00:09:05,320
Diagnose, trust wound number three.

241
00:09:05,320 –> 00:09:06,920
Token theft scenarios.

242
00:09:06,920 –> 00:09:10,080
When a token gets stolen, conditional access feels unheard.

243
00:09:10,080 –> 00:09:11,480
It’s set boundaries at sign-in,

244
00:09:11,480 –> 00:09:14,040
but the session kept walking without checking back in.

245
00:09:14,040 –> 00:09:16,360
It’s not misbehaving, it’s stuck, honoring a promise

246
00:09:16,360 –> 00:09:17,720
it can’t re-verify.

247
00:09:17,720 –> 00:09:18,760
And attackers know this.

248
00:09:18,760 –> 00:09:19,960
They don’t argue with your MFA.

249
00:09:19,960 –> 00:09:21,160
They borrow your session.

250
00:09:21,160 –> 00:09:21,960
Why this matters?

251
00:09:21,960 –> 00:09:24,080
Once an attacker holds a valid refresh token

252
00:09:24,080 –> 00:09:25,520
or a long-lived session,

253
00:09:25,520 –> 00:09:28,280
your beautiful policies become background noise.

254
00:09:28,280 –> 00:09:31,800
The risk shifts from can they log in to how long can they linger?

255
00:09:31,800 –> 00:09:33,400
If you shorten exposure

256
00:09:33,400 –> 00:09:36,040
and make the session reproof itself under the right conditions,

257
00:09:36,040 –> 00:09:37,040
you take back control.

258
00:09:37,040 –> 00:09:40,840
That’s how your system finds its rhythm again after shock.

259
00:09:40,840 –> 00:09:43,080
The thing most people miss is the difference between

260
00:09:43,080 –> 00:09:45,600
initial authentication and ongoing authorization.

261
00:09:45,600 –> 00:09:46,760
You gated the front door,

262
00:09:46,760 –> 00:09:48,640
but you left the hallway lights on forever.

263
00:09:48,640 –> 00:09:51,240
Sign-in frequency, continuous access evaluation

264
00:09:51,240 –> 00:09:54,080
and contact sensitive re-auth are how we gently ask,

265
00:09:54,080 –> 00:09:55,160
are you still you?

266
00:09:55,160 –> 00:09:56,480
Is this still that device?

267
00:09:56,480 –> 00:09:57,560
Has risk changed?

268
00:09:57,560 –> 00:09:58,680
Here’s the better pattern.

269
00:09:58,680 –> 00:10:00,400
First, reduce exposure windows,

270
00:10:00,400 –> 00:10:02,680
set sign-in frequency for sensitive apps and roles

271
00:10:02,680 –> 00:10:05,240
so tokens must represent proof more often.

272
00:10:05,240 –> 00:10:07,120
Pair that with continuous access evaluation,

273
00:10:07,120 –> 00:10:09,160
so sessions react to changes in risk,

274
00:10:09,160 –> 00:10:11,440
device state password resets and revoke tokens

275
00:10:11,440 –> 00:10:12,520
in near real time.

276
00:10:12,520 –> 00:10:15,280
Second, raise the bar for sensitive actions.

277
00:10:15,280 –> 00:10:17,040
Use authentication context to require

278
00:10:17,040 –> 00:10:19,360
phishing resistant MFA for admin portals,

279
00:10:19,360 –> 00:10:22,120
data export, e-discovery and payment approvals.

280
00:10:22,120 –> 00:10:24,640
Third, bind sessions to more than just a user.

281
00:10:24,640 –> 00:10:26,840
Consider device trust and risk signals,

282
00:10:26,840 –> 00:10:28,600
so stolen tokens don’t travel well.

283
00:10:28,600 –> 00:10:31,440
Let me show you exactly how to build that high sensitivity lane.

284
00:10:31,440 –> 00:10:33,880
Create an authentication context named high sensitivity.

285
00:10:33,880 –> 00:10:36,640
Configure a policy that when this context is required,

286
00:10:36,640 –> 00:10:39,040
demands a phishing resistant authentication strength

287
00:10:39,040 –> 00:10:41,680
and a compliant or hybrid joint device.

288
00:10:41,680 –> 00:10:44,320
Enable continuous access evaluation for the apps

289
00:10:44,320 –> 00:10:46,880
tied to that context and set a short sign-in frequency

290
00:10:46,880 –> 00:10:47,920
hours not days.

291
00:10:47,920 –> 00:10:50,040
Then, tag admin portals and critical apps

292
00:10:50,040 –> 00:10:51,440
to require that context.

293
00:10:51,440 –> 00:10:53,480
The result, an attacker holding a token

294
00:10:53,480 –> 00:10:55,320
from an unmanaged browser can’t reuse it

295
00:10:55,320 –> 00:10:56,840
to touch admin endpoints.

296
00:10:56,840 –> 00:10:59,640
And even if they land a user session, it ages quickly.

297
00:10:59,640 –> 00:11:01,360
A quick win you can do today.

298
00:11:01,360 –> 00:11:04,080
Review, remember MFA or persistent browser settings

299
00:11:04,080 –> 00:11:04,840
for your tenant.

300
00:11:04,840 –> 00:11:06,920
If it’s broad and long, that’s a quiet invitation

301
00:11:06,920 –> 00:11:08,200
to token comfort.

302
00:11:08,200 –> 00:11:10,600
Tighten it for sensitive apps while leaving user-friendly

303
00:11:10,600 –> 00:11:12,320
defaults for low-risk tools.

304
00:11:12,320 –> 00:11:14,120
It’s a karma boundary, not a punishment.

305
00:11:14,120 –> 00:11:15,640
Now here’s where most people mess up.

306
00:11:15,640 –> 00:11:18,280
They enable strong auth once, feel safe,

307
00:11:18,280 –> 00:11:21,400
and forget to scope it to the places that matter most.

308
00:11:21,400 –> 00:11:23,160
Or they ignore token binding entirely,

309
00:11:23,160 –> 00:11:25,280
letting a refreshed token row between devices

310
00:11:25,280 –> 00:11:27,040
and networks without consequence.

311
00:11:27,040 –> 00:11:29,400
Or they fail to react to risk high signals,

312
00:11:29,400 –> 00:11:31,160
letting sessions live through a storm.

313
00:11:31,160 –> 00:11:33,280
Those choices don’t feel risky in the moment.

314
00:11:33,280 –> 00:11:35,200
They feel convenient, but they teach your system

315
00:11:35,200 –> 00:11:36,920
to trust a memory, not the present.

316
00:11:36,920 –> 00:11:38,440
Let’s walk the logs together.

317
00:11:38,440 –> 00:11:41,080
In enter sign-in logs add conditional access result,

318
00:11:41,080 –> 00:11:42,680
policy name and details.

319
00:11:42,680 –> 00:11:44,760
Add session lifetime or token information fields

320
00:11:44,760 –> 00:11:47,280
if available plus IP and device info.

321
00:11:47,280 –> 00:11:50,320
You’re looking for reuse patterns, same user,

322
00:11:50,320 –> 00:11:53,480
multiple IPs, short intervals, audit device claims,

323
00:11:53,480 –> 00:11:56,000
filter for sign-ins that succeeded without a CA decision

324
00:11:56,000 –> 00:11:57,520
on apps that should be protected.

325
00:11:57,520 –> 00:12:00,200
Check the CA decision and authentication requirements fields

326
00:12:00,200 –> 00:12:01,400
for sensitive apps.

327
00:12:01,400 –> 00:12:03,640
Do they show strong auth and a recent sign-in

328
00:12:03,640 –> 00:12:05,520
or did a long session slip through?

329
00:12:05,520 –> 00:12:08,040
If you spot repeated access from an unmanaged device

330
00:12:08,040 –> 00:12:10,320
to an admin portal, that’s a sign you haven’t required

331
00:12:10,320 –> 00:12:12,400
the right authentication context there.

332
00:12:12,400 –> 00:12:14,440
A micro story, a team saw export spikes

333
00:12:14,440 –> 00:12:17,840
from a finance app at 2am, same user, different IPs,

334
00:12:17,840 –> 00:12:19,760
same browser string, no MFA prompts

335
00:12:19,760 –> 00:12:21,280
because the session was warm.

336
00:12:21,280 –> 00:12:23,080
They added a high sensitivity context,

337
00:12:23,080 –> 00:12:25,840
set sign-in frequency to four hours, enabled CAE,

338
00:12:25,840 –> 00:12:29,200
and required phishing resistant auth plus compliant device.

339
00:12:29,200 –> 00:12:30,800
The next night, the same pattern hit.

340
00:12:30,800 –> 00:12:32,600
This time, the session re-challenged

341
00:12:32,600 –> 00:12:34,520
and failed on device requirement.

342
00:12:34,520 –> 00:12:35,480
The app slept well.

343
00:12:35,480 –> 00:12:37,040
The reason this works is simple,

344
00:12:37,040 –> 00:12:38,720
we stopped trusting yesterday’s proof.

345
00:12:38,720 –> 00:12:40,520
We asked the session to stay present

346
00:12:40,520 –> 00:12:42,920
on a healthy device with strong credentials

347
00:12:42,920 –> 00:12:44,600
and to respond when risk changes.

348
00:12:44,600 –> 00:12:46,080
That’s not cruelty, that’s care.

349
00:12:46,080 –> 00:12:47,920
And your conditional access can finally exhale

350
00:12:47,920 –> 00:12:49,440
because it knows how to end a relationship

351
00:12:49,440 –> 00:12:52,440
that’s no longer safe and build the calming baseline.

352
00:12:52,440 –> 00:12:54,640
Policies that set healthy boundaries.

353
00:12:54,640 –> 00:12:57,720
Your policy engine needs a simpler home, fewer rules,

354
00:12:57,720 –> 00:12:58,960
clearer lanes.

355
00:12:58,960 –> 00:13:00,920
Blocked by default lowers its anxiety

356
00:13:00,920 –> 00:13:02,560
because every sign in is covered

357
00:13:02,560 –> 00:13:05,240
and there are no quiet gaps that whisper maybe.

358
00:13:05,240 –> 00:13:07,200
We’re going to build five inclusive policies

359
00:13:07,200 –> 00:13:08,080
that work together.

360
00:13:08,080 –> 00:13:10,160
They’re broad on scope, strict on exceptions,

361
00:13:10,160 –> 00:13:11,520
and easy to read in the logs.

362
00:13:11,520 –> 00:13:13,600
And we’ll rely on authentication context

363
00:13:13,600 –> 00:13:16,640
for rare bypasses, not permanent exclusions.

364
00:13:16,640 –> 00:13:18,440
With clearer boundaries, conditional access

365
00:13:18,440 –> 00:13:19,840
can find its rhythm again.

366
00:13:19,840 –> 00:13:21,840
Start with the anchor, all users MFA.

367
00:13:21,840 –> 00:13:23,880
Scope it to all users, all cloud apps,

368
00:13:23,880 –> 00:13:26,080
exclude only your emergency access accounts,

369
00:13:26,080 –> 00:13:27,400
use authentication strength

370
00:13:27,400 –> 00:13:29,320
so you can evolve from classic MFA

371
00:13:29,320 –> 00:13:30,880
to phishing resistant credentials

372
00:13:30,880 –> 00:13:32,600
without rewriting everything.

373
00:13:32,600 –> 00:13:35,560
Grant access with require multi factor authentication

374
00:13:35,560 –> 00:13:37,120
and prefer a defined strength

375
00:13:37,120 –> 00:13:38,840
like phishing resistant, where supported

376
00:13:38,840 –> 00:13:40,680
while allowing a practical baseline strength

377
00:13:40,680 –> 00:13:42,240
for general apps.

378
00:13:42,240 –> 00:13:44,320
Add session controls with sign-in frequency

379
00:13:44,320 –> 00:13:47,360
that fits your environment, shorter for sensitive workloads,

380
00:13:47,360 –> 00:13:48,840
reasonable for collaboration.

381
00:13:48,840 –> 00:13:52,160
This gives universal coverage and a predictable prompt story.

382
00:13:52,160 –> 00:13:54,600
The second lane is unmanaged device step-up.

383
00:13:54,600 –> 00:13:57,520
Same inclusive scope, all users, all cloud apps,

384
00:13:57,520 –> 00:13:59,600
but target devices by state.

385
00:13:59,600 –> 00:14:01,760
Use filters for devices to catch registered

386
00:14:01,760 –> 00:14:03,600
or not compliant or unknown.

387
00:14:03,600 –> 00:14:04,960
Don’t hardblock by default.

388
00:14:04,960 –> 00:14:07,360
Grant access if the user meets a higher authentication

389
00:14:07,360 –> 00:14:08,800
strength and apply session limits

390
00:14:08,800 –> 00:14:10,240
and app enforced restrictions.

391
00:14:10,240 –> 00:14:12,000
Disable persistent browser sessions here

392
00:14:12,000 –> 00:14:14,360
and reduced token lifetimes for these parts.

393
00:14:14,360 –> 00:14:16,640
This keeps personal devices at a respectful distance

394
00:14:16,640 –> 00:14:19,160
without pushing people into risky exclusions.

395
00:14:19,160 –> 00:14:20,800
Third, admin strong auth only.

396
00:14:20,800 –> 00:14:23,440
Scope to privileged, role members and admin portals

397
00:14:23,440 –> 00:14:25,280
require phishing resistant strength

398
00:14:25,280 –> 00:14:28,400
and either a compliant or hybrid joint device.

399
00:14:28,400 –> 00:14:31,520
Add sign-in frequency that’s measured in hours, not days

400
00:14:31,520 –> 00:14:34,120
and ensure continuous access evaluation is effective

401
00:14:34,120 –> 00:14:37,520
for these services, no exceptions, no location carve outs,

402
00:14:37,520 –> 00:14:39,440
no remember me.

403
00:14:39,440 –> 00:14:41,200
This is where you set the firmest boundary.

404
00:14:41,200 –> 00:14:43,160
If an admin session can’t prove device health

405
00:14:43,160 –> 00:14:45,920
and strong credentials, it waits outside.

406
00:14:45,920 –> 00:14:47,960
Fourth, emergency minimal context.

407
00:14:47,960 –> 00:14:50,000
This is your safety valve, not a side door.

408
00:14:50,000 –> 00:14:53,080
Create an authentication context named emergency bypass.

409
00:14:53,080 –> 00:14:54,720
The policy that enforces it requires

410
00:14:54,720 –> 00:14:57,200
MFA at a minimum, records device risk

411
00:14:57,200 –> 00:14:58,800
and shortened session to one hour.

412
00:14:58,800 –> 00:15:02,200
You’ll never exclude users or locations to help in a crisis.

413
00:15:02,200 –> 00:15:04,160
You’ll require them to present this context,

414
00:15:04,160 –> 00:15:06,920
which they can only obtain with approval and a change record.

415
00:15:06,920 –> 00:15:08,040
Every use is auditable.

416
00:15:08,040 –> 00:15:10,240
The boundary bends briefly then straightens.

417
00:15:10,240 –> 00:15:12,400
Fifth, token hygiene and CAE.

418
00:15:12,400 –> 00:15:15,080
Apply a policy set that standardizes sign-in frequency

419
00:15:15,080 –> 00:15:17,000
across critical apps and enables re-oothed

420
00:15:17,000 –> 00:15:18,360
when risk changes.

421
00:15:18,360 –> 00:15:20,320
Pair this with targeted sign-in frequency

422
00:15:20,320 –> 00:15:23,640
for data export systems, finance, HR and admin portals.

423
00:15:23,640 –> 00:15:25,920
Where supported, rely on continuous access evaluation,

424
00:15:25,920 –> 00:15:27,760
so password resets, token revocations

425
00:15:27,760 –> 00:15:29,400
and risk changes cut sessions short.

426
00:15:29,400 –> 00:15:31,880
This policy family keeps sessions present.

427
00:15:31,880 –> 00:15:33,440
It asks them to check in regularly,

428
00:15:33,440 –> 00:15:36,360
so a stolen token doesn’t become a week-long roommate.

429
00:15:36,360 –> 00:15:39,080
Let’s talk implementation flow so the set stays calm.

430
00:15:39,080 –> 00:15:40,880
Template each policy with inclusive scopes

431
00:15:40,880 –> 00:15:42,480
and minimal interdependence.

432
00:15:42,480 –> 00:15:44,800
Prioritize evaluation order by clarity.

433
00:15:44,800 –> 00:15:47,400
Universal MFA first, then device step-up,

434
00:15:47,400 –> 00:15:50,360
then admin controls, then context, then hygiene.

435
00:15:50,360 –> 00:15:52,760
You’re not scripting order, you’re reducing overlap,

436
00:15:52,760 –> 00:15:54,600
so the combined result is obvious.

437
00:15:54,600 –> 00:15:57,720
In policy descriptions, write the intent in plain language.

438
00:15:57,720 –> 00:16:00,320
Baseline MFA for every user and app.

439
00:16:00,320 –> 00:16:03,040
Step-up for unmanaged devices, admins must use

440
00:16:03,040 –> 00:16:05,200
strong auth and managed devices on a sunny day.

441
00:16:05,200 –> 00:16:07,080
Your future self will thank you in the logs.

442
00:16:07,080 –> 00:16:09,280
Here’s a quick win that feels great immediately.

443
00:16:09,280 –> 00:16:13,160
Create the all-cloud apps, require MFA baseline with strengths.

444
00:16:13,160 –> 00:16:14,480
Deploy in report only for a week

445
00:16:14,480 –> 00:16:16,720
while you shadow it with the unmanaged device step-up policy

446
00:16:16,720 –> 00:16:17,760
also report only.

447
00:16:17,760 –> 00:16:21,720
Watch sign-ins move from not applied to MFA would be required

448
00:16:21,720 –> 00:16:24,560
and stronger auth would be required on BYOD.

449
00:16:24,560 –> 00:16:26,720
Fix the noisy edge cases then enforce.

450
00:16:26,720 –> 00:16:28,840
You’ll see coverage jump without chaos.

451
00:16:28,840 –> 00:16:30,160
Now, the mistakes to avoid.

452
00:16:30,160 –> 00:16:32,800
Don’t overlap apps scopes in ways that fight.

453
00:16:32,800 –> 00:16:36,400
All-cloud apps plus specific admin portals is fine,

454
00:16:36,400 –> 00:16:39,040
but two different all-cloud apps with conflicting grants

455
00:16:39,040 –> 00:16:40,520
will produce odd results.

456
00:16:40,520 –> 00:16:43,920
Don’t mix user exclusions with context-based exceptions.

457
00:16:43,920 –> 00:16:46,640
Pick context so the audit trail is clean.

458
00:16:46,640 –> 00:16:49,400
Don’t forget service accounts and workload identities.

459
00:16:49,400 –> 00:16:52,280
Give them dedicated policies that require managed identities

460
00:16:52,280 –> 00:16:53,680
or certificate-based flows

461
00:16:53,680 –> 00:16:56,480
and explicitly block interactive sign-in for them.

462
00:16:56,480 –> 00:16:58,040
Before and after matters.

463
00:16:58,040 –> 00:17:01,120
Before 10 narrow policies each with their own include groups

464
00:17:01,120 –> 00:17:03,960
and long exclude lists, inconsistent grant controls

465
00:17:03,960 –> 00:17:05,120
and special locations.

466
00:17:05,120 –> 00:17:08,440
After five larger policies with inclusive scopes,

467
00:17:08,440 –> 00:17:11,120
no permanent exclusions and one place,

468
00:17:11,120 –> 00:17:13,920
authentication context for controlled bypass,

469
00:17:13,920 –> 00:17:16,320
the engine stops juggling and starts protecting.

470
00:17:16,320 –> 00:17:18,000
The log stop whispering not applied

471
00:17:18,000 –> 00:17:20,920
and starts stating MFA required, strong auth required

472
00:17:20,920 –> 00:17:22,320
or blocked until healthier.

473
00:17:22,320 –> 00:17:24,720
Monitoring hooks keep this baseline peaceful.

474
00:17:24,720 –> 00:17:25,960
Track two, KPIs.

475
00:17:25,960 –> 00:17:28,440
Percentage of sign-ins covered by any conditional access

476
00:17:28,440 –> 00:17:31,320
decision and percentage that met MFA or your defined strengths,

477
00:17:31,320 –> 00:17:35,720
target at least 99% coverage and 98% MFA were applicable.

478
00:17:35,720 –> 00:17:39,000
When coverage dips, you’ll know a scope changed or an app escaped.

479
00:17:39,000 –> 00:17:41,160
When MFA drops, you’ll see where stronger auth

480
00:17:41,160 –> 00:17:43,200
isn’t being required as intended.

481
00:17:43,200 –> 00:17:45,040
Tie this baseline to your change process.

482
00:17:45,040 –> 00:17:48,440
Any change to a policy, its scope or its exclusion list demands

483
00:17:48,440 –> 00:17:50,520
a ticket and owner and an expiry.

484
00:17:50,520 –> 00:17:53,520
Authentication context grants need the same care,

485
00:17:53,520 –> 00:17:56,920
who asked, who approved, why and when it ends.

486
00:17:56,920 –> 00:17:58,760
And built-in alert for exclusion list changes

487
00:17:58,760 –> 00:18:00,920
so you hear the moment a boundary moves.

488
00:18:00,920 –> 00:18:03,880
With gentle discipline, your conditional access will feel heard,

489
00:18:03,880 –> 00:18:06,520
supported and ready for the next rollout.

490
00:18:06,520 –> 00:18:10,960
Unsafe rollout, test plan, report only and rollback checklists.

491
00:18:10,960 –> 00:18:13,840
Change scares identity, sudden enforcement spikes cortisol,

492
00:18:13,840 –> 00:18:16,440
so we coach conditional access through rehearsal first,

493
00:18:16,440 –> 00:18:18,680
then performance report only is rehearsal,

494
00:18:18,680 –> 00:18:21,880
no harm for learning, here’s the plan, three waves, one rhythm.

495
00:18:21,880 –> 00:18:25,600
Wave one, admins and admin portals, wave two, high-risk apps and rolls,

496
00:18:25,600 –> 00:18:26,480
wave three.

497
00:18:26,480 –> 00:18:29,440
Everyone, all apps, each wave spends a week in report only,

498
00:18:29,440 –> 00:18:31,600
then enforces once the noise is quiet.

499
00:18:31,600 –> 00:18:34,880
And boundaries are a gift, so we keep a rollback ready at every step.

500
00:18:34,880 –> 00:18:36,400
Start by shadowing your baseline.

501
00:18:36,400 –> 00:18:39,080
Duplicate each policy you built and set it to report only.

502
00:18:39,080 –> 00:18:42,440
Scope is inclusive, exclude only emergency access.

503
00:18:42,440 –> 00:18:45,720
In descriptions, write shadow baseline report only,

504
00:18:45,720 –> 00:18:47,920
so ops can see its intent in the logs.

505
00:18:47,920 –> 00:18:50,600
Now with patience, let it watch traffic for seven days.

506
00:18:50,600 –> 00:18:53,000
You’re listening for stress points, not perfection.

507
00:18:53,000 –> 00:18:56,000
Use the what if tool to pre-flight edge cases.

508
00:18:56,000 –> 00:18:59,240
Pick a test user, device state, location and the app.

509
00:18:59,240 –> 00:19:02,760
Validate the expected grant controls and session rules.

510
00:19:02,760 –> 00:19:07,200
If the what if says MFA required, but sign-in logs show not applied,

511
00:19:07,200 –> 00:19:09,040
you found a scope mismatch.

512
00:19:09,040 –> 00:19:10,240
Fix that before you move.

513
00:19:10,240 –> 00:19:11,720
Now read the room through logs.

514
00:19:11,720 –> 00:19:13,160
Open sign-in logs.

515
00:19:13,160 –> 00:19:17,280
Add conditional access result, policy name applied, not applied and grant controls.

516
00:19:17,280 –> 00:19:20,160
For report only policies, look at report only would have decisions.

517
00:19:20,160 –> 00:19:24,240
You want to see MFA would be required, strong auth would be required,

518
00:19:24,240 –> 00:19:26,800
and minimal unexpected block would be applied.

519
00:19:26,800 –> 00:19:31,040
Investigate any surge in block for service principles or legacy flows.

520
00:19:31,040 –> 00:19:33,840
Those need their own policies or migration plans.

521
00:19:33,840 –> 00:19:35,720
Before you enforce, stage comes.

522
00:19:35,720 –> 00:19:38,760
Tell admins what will change, how strong auth feels and where to get help.

523
00:19:38,760 –> 00:19:40,880
Share the emergency context process.

524
00:19:40,880 –> 00:19:42,480
Calm voices lower friction.

525
00:19:42,480 –> 00:19:45,280
Enforced wave 1 on a weekday morning with support on standby,

526
00:19:45,280 –> 00:19:48,640
flip admin strong auth and token hygiene from report only to own.

527
00:19:48,640 –> 00:19:49,800
Keep the others shadowing.

528
00:19:49,800 –> 00:19:51,960
Watch for entra errors, bikes and ticket volume.

529
00:19:51,960 –> 00:19:56,760
If failure rates climb beyond your agreed threshold, pause, diagnose or rollback.

530
00:19:56,760 –> 00:19:58,360
Your rollback is simple and kind.

531
00:19:58,360 –> 00:20:01,680
Pre-approved toggles to revert policies to report only.

532
00:20:01,680 –> 00:20:03,760
Document the exact settings you’d restore.

533
00:20:03,760 –> 00:20:06,240
Keep the emergency bypass context live and tested.

534
00:20:06,240 –> 00:20:10,960
Maintain a change ticket per policy with owner and timestamp so you can unwind confidently.

535
00:20:10,960 –> 00:20:12,600
Wave 2 brings high risk apps.

536
00:20:12,600 –> 00:20:17,040
Attach the high sensitivity context to finance, HRE discovery and export paths.

537
00:20:17,040 –> 00:20:20,080
Again, a week of report only, then enforce.

538
00:20:20,080 –> 00:20:24,840
Confirm that unmanaged devices hit step up and that CE-driven re-auth events behave.

539
00:20:24,840 –> 00:20:26,360
Wave 3 is everyone.

540
00:20:26,360 –> 00:20:29,480
Turn on all users, MFA and unmanaged device step up.

541
00:20:29,480 –> 00:20:33,080
Validate that coverage rises and failure rates stay stable.

542
00:20:33,080 –> 00:20:33,720
Then breathe.

543
00:20:33,720 –> 00:20:34,640
You didn’t force it.

544
00:20:34,640 –> 00:20:40,440
You let conditional access find its rhythm with rehearsal, permission and a safety net.

545
00:20:40,440 –> 00:20:41,520
Watchful piece.

546
00:20:41,520 –> 00:20:43,480
Monitoring and alerts that actually help.

547
00:20:43,480 –> 00:20:46,160
Once live, your conditional access needs steady feedback.

548
00:20:46,160 –> 00:20:47,440
Not noise, not panic.

549
00:20:47,440 –> 00:20:51,360
A calm heartbeat that tells you it’s present, it’s protecting and where it needs care.

550
00:20:51,360 –> 00:20:56,280
We’ll set up three signals and a weekly rhythm that keeps trust intact without burning anyone out.

551
00:20:56,280 –> 00:20:59,600
The thing most people miss is that coverage is your north star.

552
00:20:59,600 –> 00:21:04,280
If a sign isn’t touched by any CA policy, it’s living outside the boundaries you just set.

553
00:21:04,280 –> 00:21:06,160
So we start with two simple KPIs.

554
00:21:06,160 –> 00:21:07,320
Coverage and strength.

555
00:21:07,320 –> 00:21:11,560
Coverage is the percentage of interactive sign-ins with any conditional access decision.

556
00:21:11,560 –> 00:21:15,880
Strength is the percentage of those sign-ins that satisfy MFA or your defined authentication

557
00:21:15,880 –> 00:21:16,880
strength.

558
00:21:16,880 –> 00:21:18,760
If you remember nothing else, remember this.

559
00:21:18,760 –> 00:21:19,760
Track both.

560
00:21:19,760 –> 00:21:21,960
High coverage without strength is comfort theater.

561
00:21:21,960 –> 00:21:24,160
High strength without coverage is selective care.

562
00:21:24,160 –> 00:21:26,760
Let’s help it find its rhythm with practical queries.

563
00:21:26,760 –> 00:21:31,480
In your sign-in logs, add columns for conditional access result, policy name and authentication

564
00:21:31,480 –> 00:21:32,480
requirements.

565
00:21:32,480 –> 00:21:37,040
A saved view that counts sign-ins by day where CA decision is present versus not applied.

566
00:21:37,040 –> 00:21:38,320
That’s your coverage line.

567
00:21:38,320 –> 00:21:42,320
Create a second view that counts sign-ins where MFA or your chosen strength was required

568
00:21:42,320 –> 00:21:43,320
and satisfied.

569
00:21:43,320 –> 00:21:44,560
That’s your strength line.

570
00:21:44,560 –> 00:21:47,040
Keep both lines visible on a simple dashboard.

571
00:21:47,040 –> 00:21:48,960
The goal is boring consistency.

572
00:21:48,960 –> 00:21:53,080
Coverage add or above 99% strength add or above 98% where applicable.

573
00:21:53,080 –> 00:21:55,040
Now the three alerts that actually help.

574
00:21:55,040 –> 00:21:56,640
First a coverage drop alert.

575
00:21:56,640 –> 00:22:01,080
If coverage dips below your threshold for any 30-minute window, you get a nudge.

576
00:22:01,080 –> 00:22:02,080
First a siren.

577
00:22:02,080 –> 00:22:07,240
A nudge to check whether a scope changed a new app onboarded without CA or a policy was disabled.

578
00:22:07,240 –> 00:22:09,040
Second an exclusion growth alert.

579
00:22:09,040 –> 00:22:14,240
Whenever any CA policies exclusion list changes, user group application you get a change notification

580
00:22:14,240 –> 00:22:16,080
with who edited it and what changed.

581
00:22:16,080 –> 00:22:17,080
That’s not about blame.

582
00:22:17,080 –> 00:22:18,080
It’s about awareness.

583
00:22:18,080 –> 00:22:19,080
Boundaries moved.

584
00:22:19,080 –> 00:22:20,080
Let’s see why.

585
00:22:20,080 –> 00:22:22,080
Third high risk sign-ins with not applied.

586
00:22:22,080 –> 00:22:25,960
If any high risk sign-in lands without a CA decision, raise a flag.

587
00:22:25,960 –> 00:22:29,560
That means risk saw something but your boundaries didn’t show up to help.

588
00:22:29,560 –> 00:22:31,320
When is the shortcut nobody teaches?

589
00:22:31,320 –> 00:22:33,640
Tie these alerts to owners, not inboxes.

590
00:22:33,640 –> 00:22:36,520
Each policy and each KPI has a name steward.

591
00:22:36,520 –> 00:22:38,640
When coverage dips an owner checks scope.

592
00:22:38,640 –> 00:22:41,680
When exclusions change an owner confirms expiry and purpose.

593
00:22:41,680 –> 00:22:46,320
When high risk bypasses appear an owner validates that the right apps require the right context.

594
00:22:46,320 –> 00:22:47,320
You’re not just watching.

595
00:22:47,320 –> 00:22:48,320
You’re caring with intention.

596
00:22:48,320 –> 00:22:51,120
Let me show you exactly how to read the bypasses.

597
00:22:51,120 –> 00:22:55,400
Build a saved filter for sign-ins where conditional access result equals not applied.

598
00:22:55,400 –> 00:22:58,280
Add app, user client app and location.

599
00:22:58,280 –> 00:22:59,280
Sort by count.

600
00:22:59,280 –> 00:23:01,040
You’re looking for clusters that shouldn’t exist.

601
00:23:01,040 –> 00:23:04,240
A service principle signing in interactively, that’s a misscoped identity.

602
00:23:04,240 –> 00:23:08,120
A legacy protocol touching a protected app, that’s a migration task.

603
00:23:08,120 –> 00:23:11,760
A guest user hitting an internal app with no CA decision.

604
00:23:11,760 –> 00:23:16,760
That app likely missed all cloud apps or sits under a different publisher and needs tagging.

605
00:23:16,760 –> 00:23:18,680
This filter is your quiet detective.

606
00:23:18,680 –> 00:23:19,960
A quick win you can do today.

607
00:23:19,960 –> 00:23:24,200
Turn on and alert for any policy moving from enable to report only or to disabled and

608
00:23:24,200 –> 00:23:26,760
for any change to the all-user scope.

609
00:23:26,760 –> 00:23:28,880
These two movements cause most surprises.

610
00:23:28,880 –> 00:23:34,440
I’ve prepared that with a daily digest listing top 10 apps by not applied sign-ins and top 10 users by MFA not satisfied.

611
00:23:34,440 –> 00:23:35,720
It’s not a wall of data.

612
00:23:35,720 –> 00:23:37,200
It’s a morning check-in.

613
00:23:37,200 –> 00:23:38,560
Now here’s where most people mess up.

614
00:23:38,560 –> 00:23:41,920
They set thresholds so tight that every blip becomes an alarm.

615
00:23:41,920 –> 00:23:46,760
Or they ignore service principles and non-interactive flows, even though those identities hold powerful keys.

616
00:23:46,760 –> 00:23:49,840
Or they never review the report only would have lines.

617
00:23:49,840 –> 00:23:52,440
So there are shadow policies drift from reality.

618
00:23:52,440 –> 00:23:54,320
We want to avoid learned helplessness.

619
00:23:54,320 –> 00:23:56,680
If the system cries wolf people stop listening.

620
00:23:56,680 –> 00:23:58,800
Keep alert scarce, specific and owned.

621
00:23:58,800 –> 00:24:01,160
Let’s anchor with the KPI board you’ll actually use.

622
00:24:01,160 –> 00:24:05,080
Top row, coverage percentage, strength percentage and exclusions count trend.

623
00:24:05,080 –> 00:24:06,720
Info flatlines at healthy levels.

624
00:24:06,720 –> 00:24:13,240
Second row, top bypassing apps, top bypassing locations and changes in CA policy scopes over the last seven days.

625
00:24:13,240 –> 00:24:18,760
Third row, high risk sign-ins without CA decision and admin sign-ins that lack strong auth.

626
00:24:18,760 –> 00:24:19,920
Review weekly.

627
00:24:19,920 –> 00:24:22,120
Investigate deviations within 24 hours.

628
00:24:22,120 –> 00:24:23,960
Not with blame with curiosity.

629
00:24:23,960 –> 00:24:26,360
Why did coverage dip yesterday at noon?

630
00:24:26,360 –> 00:24:27,560
Maybe a new app launched.

631
00:24:27,560 –> 00:24:28,080
Great.

632
00:24:28,080 –> 00:24:31,120
Tag it, bring it under all cloud apps, confirm the right context.

633
00:24:31,120 –> 00:24:32,760
Close the loop with change management.

634
00:24:32,760 –> 00:24:38,280
Every policy edit requires an owner, a reason and an expiry when it’s a temporary exception.

635
00:24:38,280 –> 00:24:41,040
Your exclusion growth alert isn’t just a notification.

636
00:24:41,040 –> 00:24:43,840
It’s a prompt to add that expiry and book a review.

637
00:24:43,840 –> 00:24:45,800
Your coverage drop alert isn’t a failure.

638
00:24:45,800 –> 00:24:47,960
It’s the system asking for alignment.

639
00:24:47,960 –> 00:24:51,360
This is how you keep conditional access in therapy, not triage.

640
00:24:51,360 –> 00:24:53,560
It gets to be transparent, consistent and hurt.

641
00:24:53,560 –> 00:24:54,720
And boundaries are a gift.

642
00:24:54,720 –> 00:24:57,000
With gentle monitoring, you’re not micromanaging.

643
00:24:57,000 –> 00:25:00,720
You’re holding a steady container so CA can keep doing the quiet work protecting everyone

644
00:25:00,720 –> 00:25:02,800
all day without drama.

645
00:25:02,800 –> 00:25:04,120
Here’s the takeaway.

646
00:25:04,120 –> 00:25:06,040
Your conditional access wasn’t broken.

647
00:25:06,040 –> 00:25:08,360
It was trusting without boundaries.

648
00:25:08,360 –> 00:25:12,560
Inclusive scopes, time-bound contexts and steady monitoring restore its balance.

649
00:25:12,560 –> 00:25:17,160
If this helped, try the baseline template, shadow it in report only for seven days and

650
00:25:17,160 –> 00:25:20,120
wire the three alerts so changes never go silent.

651
00:25:20,120 –> 00:25:24,560
Subscribe and watch the next episode on authentication context patterns and token binding hardening.