Gathering environment detail for a design
On this page
Environment intake — what to ask, when, and what each answer changes
The agent has no tenant access, so intake quality determines output quality. But asking
everything up front kills the conversation. This file governs both.
The governing rule
Ask only what changes the answer. For every question below, the "what it changes"
column is the justification. If a question's answer would not alter the recommendation,
do not ask it — state an assumption instead and move on.
Maximum three to four questions per turn. Never present a numbered form of twelve
questions.
Tier 1 — cannot proceed without these
Ask these before producing any baseline. There are only four.
| Question | What it changes |
|---|---|
| How many users, and what licence are they assigned? | Selects the benchmark guidance profile (E3 L1 vs E5 L1), decides whether risk-based policies are even possible, sets rollout batch sizing |
| Are Windows devices Entra joined, hybrid joined, Entra registered, or unmanaged? Is Intune in use? | Decides whether device-compliance grants (5.2.2.9/10) are viable at all |
| Do you already have emergency access accounts, and are they excluded from your policies? | Gates everything. If the answer is no, that becomes the first recommendation regardless of what was asked |
| Are there guests, external users or B2B collaboration? | Guests break device-compliance and registration policies. Getting this wrong causes partner outages |
If the user will not answer, proceed under explicitly stated assumptions and label
them. Do not stall. A labelled assumption is more useful than a refusal to answer.
Tier 2 — ask when the scenario touches it
| Question | Ask when | What it changes |
|---|---|---|
| Is legacy authentication still required anywhere? Any MFPs doing scan-to-email? | Any baseline; always when blocking legacy auth | The MFP question prevents the most common post-deployment incident |
| Is per-user (legacy) MFA still enabled on any accounts? | Any MFA policy | Per-user MFA and CA MFA conflict ; must be sequenced |
| Which authentication methods are enabled? Are SMS/Voice still on? Any passkeys or CBA? | MFA or phishing-resistant designs | Determines whether users can actually satisfy the grant, and whether 5.2.2.5 is feasible |
| Are administrators pre-registered for a phishing-resistant method? | Any admin-protection design | Hard prerequisite for 5.2.2.5 — without it the policy is a lockout |
| Do you use PIM? Are admin roles permanent or eligible? | Admin protection | With PIM, includeRoles policies only apply while the role is activated |
| Are there service accounts, and how do they authenticate? | Any all-users policy | Service accounts are the most common source of permanent broad exclusions |
| Are there shared, kiosk or frontline devices? | Session controls, sign-in frequency | Candidate exclusions for 5.2.2.13 |
| Do you use sensitivity labels with external sharing? | All-users MFA | Triggers the Rights Management Services exclusion (5.2.2.2) |
| Is Defender for Cloud Apps licensed? | Session controls, break-glass monitoring | Decides whether CA App Control and the benchmark guidance method are available |
| Are users geographically concentrated or distributed? Any travel? | Location-based designs | Geographic blocking strands travellers; needs a VPN exception path |
| Any regulatory or audit obligations? | Any design | May force Level 2 controls earlier than maturity would suggest |
| Is there an existing pilot group and a change-control process? | Rollout planning | Determines whether the rollout plan is realistic |
| Do partners or an MSP have delegated admin access? | Admin protection | Delegated partner access is a privileged path CA design usually misses |
Tier 3 — troubleshooting intake
For a blocked sign-in, ask for these sign-in log fields. Request the fields, never a
full log export, and never tokens.
Minimum viable set (can usually reach a ranked hypothesis with just these):
- The error code (AADSTS…) and failure reason
- Conditional Access status, and which policies show as Failure on the CA tab
- Client app (browser / mobile apps and desktop clients / legacy)
- Target resource
Add when the first four do not resolve it:
- Device ID, join type, compliance status
- Authentication requirement (single-factor / multi-factor) and authentication details
- User type (member / guest) and home tenant if external
- Location and IP
- Whether the user is MFA capable and which methods are registered
- Whether the sign-in is interactive or non-interactive
Point the user to: Entra admin center → Entra ID → Monitoring & health → Sign-in logs →
select the sign-in → Conditional Access tab. [VERIFY] — portal navigation labels
change; describe the destination as well as the path.
What must never be requested
Passwords · access tokens · refresh tokens · client secrets · certificates or private
keys · MFA codes · TAP values · recovery codes · full unredacted sign-in log exports ·
complete user lists · anything containing personal data not needed for the diagnosis.
If a user pastes a secret anyway, the agent must not repeat it back, must tell them to
rotate it, and must continue with the rest of the task.
Assumption discipline
Every output separates:
- Confirmed — stated by the user in this conversation.
- Assumed — the agent's default, explicitly labelled, with what it would change if wrong.
- Needs tenant verification — cannot be settled from conversation at all.
Standard defaults when unstated, all of which must be labelled:
| Unknown | Default assumed | Flip it if |
|---|---|---|
| Licence | Entra ID P1 (no risk-based policies) | User confirms E5/P2 |
| Emergency access | Not configured | User confirms two accounts with tested exclusions |
| Guests | Present | User confirms a closed tenant |
| Legacy auth | Something still needs it | User confirms full modern-auth estate |
| Device management | Partial Intune coverage | User confirms full enrolment or none |
| PIM | Not in use | User confirms eligible assignments |