conditional-access-mfa

Name: conditional-access-mfa
Author: vinayaklatthe

55installs34forks

How to install conditional-access-mfa?

vinayaklatthe/microsoft-security-skills/conditional-access-mfa

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill conditional-access-mfa

Installs into the current project.

Summary

Guidance for Microsoft Entra Conditional Access (CA) and multifactor authentication — the Zero Trust policy engine that enforces grant/block decisions based on user, device, location, app, and risk signals. Covers a baseline 6-policy set, authentication strengths for phishing-res

Files · 1

View on GitHub

SKILL.md

1	# Conditional Access & MFA
2
3	Conditional Access (CA) is the Zero Trust policy engine in Entra. It evaluates signals - user
4	/group, device state, location, application, sign-in risk - and enforces grant, block, or
5	grant-with-controls (MFA, compliant device, session controls). MFA without CA is rare; the
6	two are designed together.
7
8	## When to use
9	Enforcing adaptive, identity-centric access controls across Microsoft 365 and any Entra-
10	integrated app. Use this skill for the baseline policy set and any new policy rollout.
11
12	Do not use this skill for risk detection (`entra-id-protection`), just-in-time admin
13	elevation (`azure-pim`), or app-side OAuth permissions (`entra-id`).
14
15	## The baseline 6-policy set
16
17	Every Entra tenant in 2026 should have these six policies as the minimum, in this order.
18
19	\| # \| Policy \| Scope \| Grant control \|
20	\|---\|---\|---\|---\|
21	\| 1 \| Require MFA for admins \| All Entra admin roles \| MFA + phishing-resistant strength \|
22	\| 2 \| Require MFA for all users \| All users (excl. break-glass) \| MFA \|
23	\| 3 \| Block legacy authentication \| All users \| Block \|
24	\| 4 \| Require compliant device for M365 \| All users, M365 apps \| Compliant OR hybrid-joined \|
25	\| 5 \| Risk-based CA - sign-in risk High \| All users \| MFA (requires EID P2) \|
26	\| 6 \| Risk-based CA - user risk High \| All users \| Secure password change (requires EID P2) \|
27
28	> Rule of thumb: if a tenant doesn't have all 6, it is below the 2026 Microsoft baseline.
29	> Policies 5 and 6 require Entra ID P2; substitute with risk-based authentication strength
30	> on E3 if needed.
31
32	## Approach
33
34	1. Inventory before authoring — Export current sign-in logs to understand baseline:
35	per-app MFA usage, legacy auth volume, device compliance, named locations in use.
36	Don't author policies on assumed traffic patterns.
37	Verify: `Sign-ins` workbook shows per-app MFA % and legacy auth count.
38
39	2. Use authentication strengths, not just "Require MFA" — Authentication strengths let
40	you require phishing-resistant methods (FIDO2 passkey, Windows Hello for Business,
41	certificate-based) for high-value scopes. Plain "Require MFA" accepts SMS - still phishable.
42	Verify: admin policy grant control uses the built-in Phishing-resistant MFA*
43	authentication strength, not generic MFA.*
44
45	3. Always report-only first — New policies in report-only mode for at least 7 days.
46	Use What If to model specific user + app scenarios. Promote to On only after the
47	report-only results show no surprises.
48	*Verify: policy report-only impact > 0 sign-ins evaluated (otherwise policy isn't matching
49	anything - bad scope).*
50
51	4. Exclude break-glass on every policy — Two cloud-only emergency accounts excluded from
52	every policy, monitored on every sign-in. Document the exclusion list and review monthly.
53	*Verify: `Conditional Access Insights workbook` shows break-glass exclusion applied to all
54	enforcing policies.*
55
56	5. Session controls where needed — Sign-in frequency for sensitive apps, persistent
57	browser block on shared devices, app-enforced restrictions for Exchange/SharePoint,
58	Conditional Access App Control for in-session monitoring.
59
60	6. Policy register — Maintain a register (CSV or Sentinel watchlist) with policy intent,
61	owner, exclusions, last review. CA policies drift without this.
62
63	## Guardrails
64	- Never enforce a new policy on All users without report-only first. Most production CA
65	incidents come from this single mistake.
66	- Two break-glass accounts excluded from every policy, monitored on every sign-in.
67	Without this, a CA misconfiguration can lock out the tenant.
68	- Block legacy auth, then monitor sign-ins for 30 days. Some apps still use it -
69	surface them and remediate before complaints arrive.
70	- Phishing-resistant strength for admins, not generic MFA. SMS-based MFA for Global Admin
71	is the 2026 equivalent of a password sticky note.
72	- Don't stack 30+ policies. Each evaluation costs latency. Consolidate where condit

People who liked this also viewed

6 picks

Type

conditional-access-mfa

55installs34forks

View on GitHub

How to install conditional-access-mfa?

vinayaklatthe/microsoft-security-skills/conditional-access-mfa

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill conditional-access-mfa

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Conditional Access & MFA
2
3	Conditional Access (CA) is the Zero Trust policy engine in Entra. It evaluates signals - user
4	/group, device state, location, application, sign-in risk - and enforces grant, block, or
5	grant-with-controls (MFA, compliant device, session controls). MFA without CA is rare; the
6	two are designed together.
7
8	## When to use
9	Enforcing adaptive, identity-centric access controls across Microsoft 365 and any Entra-
10	integrated app. Use this skill for the baseline policy set and any new policy rollout.
11
12	Do not use this skill for risk detection (`entra-id-protection`), just-in-time admin
13	elevation (`azure-pim`), or app-side OAuth permissions (`entra-id`).
14
15	## The baseline 6-policy set
16
17	Every Entra tenant in 2026 should have these six policies as the minimum, in this order.
18
19	\| # \| Policy \| Scope \| Grant control \|
20	\|---\|---\|---\|---\|
21	\| 1 \| Require MFA for admins \| All Entra admin roles \| MFA + phishing-resistant strength \|
22	\| 2 \| Require MFA for all users \| All users (excl. break-glass) \| MFA \|
23	\| 3 \| Block legacy authentication \| All users \| Block \|
24	\| 4 \| Require compliant device for M365 \| All users, M365 apps \| Compliant OR hybrid-joined \|
25	\| 5 \| Risk-based CA - sign-in risk High \| All users \| MFA (requires EID P2) \|
26	\| 6 \| Risk-based CA - user risk High \| All users \| Secure password change (requires EID P2) \|
27
28	> Rule of thumb: if a tenant doesn't have all 6, it is below the 2026 Microsoft baseline.
29	> Policies 5 and 6 require Entra ID P2; substitute with risk-based authentication strength
30	> on E3 if needed.
31
32	## Approach
33
34	1. Inventory before authoring — Export current sign-in logs to understand baseline:
35	per-app MFA usage, legacy auth volume, device compliance, named locations in use.
36	Don't author policies on assumed traffic patterns.
37	Verify: `Sign-ins` workbook shows per-app MFA % and legacy auth count.
38
39	2. Use authentication strengths, not just "Require MFA" — Authentication strengths let
40	you require phishing-resistant methods (FIDO2 passkey, Windows Hello for Business,
41	certificate-based) for high-value scopes. Plain "Require MFA" accepts SMS - still phishable.
42	Verify: admin policy grant control uses the built-in Phishing-resistant MFA*
43	authentication strength, not generic MFA.*
44
45	3. Always report-only first — New policies in report-only mode for at least 7 days.
46	Use What If to model specific user + app scenarios. Promote to On only after the
47	report-only results show no surprises.
48	*Verify: policy report-only impact > 0 sign-ins evaluated (otherwise policy isn't matching
49	anything - bad scope).*
50
51	4. Exclude break-glass on every policy — Two cloud-only emergency accounts excluded from
52	every policy, monitored on every sign-in. Document the exclusion list and review monthly.
53	*Verify: `Conditional Access Insights workbook` shows break-glass exclusion applied to all
54	enforcing policies.*
55
56	5. Session controls where needed — Sign-in frequency for sensitive apps, persistent
57	browser block on shared devices, app-enforced restrictions for Exchange/SharePoint,
58	Conditional Access App Control for in-session monitoring.
59
60	6. Policy register — Maintain a register (CSV or Sentinel watchlist) with policy intent,
61	owner, exclusions, last review. CA policies drift without this.
62
63	## Guardrails
64	- Never enforce a new policy on All users without report-only first. Most production CA
65	incidents come from this single mistake.
66	- Two break-glass accounts excluded from every policy, monitored on every sign-in.
67	Without this, a CA misconfiguration can lock out the tenant.
68	- Block legacy auth, then monitor sign-ins for 30 days. Some apps still use it -
69	surface them and remediate before complaints arrive.
70	- Phishing-resistant strength for admins, not generic MFA. SMS-based MFA for Global Admin
71	is the 2026 equivalent of a password sticky note.
72	- Don't stack 30+ policies. Each evaluation costs latency. Consolidate where condit

People who liked this also viewed

6 picks

Type