Many identity security programs start with a checklist: enable MFA, restrict legacy authentication, review privileged roles, done. Months later, teams may struggle to confirm whether those controls are actually operating, whether they ever worked as intended, or what happens when someone legitimately needs an exception. The checklist told you what to configure. It never told you how you’d know it was still true.

This article is for security engineers, cloud architects, and Microsoft Entra administrators who need identity baselines a team can operate, test, and hand off — not merely an audit checkbox. The outcome is a small set of engineering habits — scoping, separating prevention from detection, defining evidence up front, and treating exceptions as tracked debt — plus a reusable record template, illustrated with a worked example around privileged administrator access.

A baseline is an engineering system, not a checklist

A checklist item says “Conditional Access requires MFA for administrators.” That’s a declaration. It says nothing about whether the policy applies to every account holding an administrative role today, whether an emergency access (break-glass) account quietly bypasses it, or whether whoever configured it a year ago would notice if it silently stopped working after a tenant change.

Declaring a control and operating a control are different disciplines. Declaring it means the setting exists somewhere in the tenant. Operating it means you can answer, on demand, whether it’s currently effective, who owns it, and what evidence would convince a skeptical reviewer — including yourself later — that it’s doing what you think it’s doing.

A baseline treated as an engineering system gives every control five attributes, not just a name:

  • Scope — which identities, applications, and conditions it applies to, and what’s explicitly excluded.
  • Implementation — the specific configuration that enforces it.
  • Evidence — the artifact proving it’s configured and, separately, that it’s operating.
  • Testing — a repeatable way to confirm it still behaves as expected after change.
  • Ownership — a named person accountable for its health and periodic review.

Whether configured through a portal or an API, an identity control can easily become a one-off setting unless the team deliberately manages it as a versioned engineering artifact. Saving a configuration is not the same as operating a control.

Start with assumptions and scope

Before writing a single Conditional Access policy, decide — and write down — what the baseline covers. An undocumented scope isn’t cautious, it’s untestable: nobody can tell whether an account outside the intended scope is a deliberate exclusion or a gap nobody noticed.

At minimum, document:

  • Identity populations — employees, contractors, guests, service accounts, and workload or agent identities. “Users” often silently means “employees with a specific license,” forgetting guests or synced on-premises accounts.
  • Applications and resources — which apps or Azure resources fall inside the baseline versus a different, possibly less mature, policy set.
  • Privilege levels — standard users, resource owners, and administrators generally warrant different baselines; one blanket policy tends to be too weak for admins or too disruptive for everyone else.
  • Licensing and prerequisites — controls like phishing-resistant authentication strengths or Privileged Identity Management depend on specific license tiers. Assuming a license the tenant doesn’t hold turns a baseline into a plan with an unstated dependency.
  • Documented exclusions — emergency access accounts, legacy accounts pending decommission, a business unit mid-migration. Exclusions aren’t forbidden; an undocumented one looks identical to a gap during an incident review.

If you can’t state who a control applies to, you probably can’t test it either.

Separate preventive and detective controls

Prevention alone is insufficient — not because it’s unreliable, but because no preventive control covers every path to the outcome you’re protecting, and any of them can be misconfigured, bypassed through a legitimate exception, or quietly disabled during a change nobody flags as security-relevant.

A Conditional Access policy blocking legacy authentication is preventive. It’s also a configuration object someone can edit, exclude a group from, or set to report-only while troubleshooting and forget to re-enable. Without a detective control watching for that drift, the policy’s actual and assumed state can diverge indefinitely.

The preventive control narrows what’s possible — a required authentication strength, a blocked protocol, limited standing access. The detective control answers whether that’s still true, and what happened on the sign-ins it didn’t cover.

This is where configuration and evidence of operation diverge. A policy screenshot proves configuration. Stronger evidence that the control is operating combines several signals: blocked legacy-authentication attempts where the platform surfaces them, confirmation that no successful legacy-authentication sign-ins occurred during the review period, a deliberate negative test attempting legacy authentication against a test account, and verification that the applied configuration matches what was intended.

Define evidence before rollout

If you decide what “proof this control works” looks like only after something goes wrong, you’ll be improvising evidence under pressure. Define the evidence model as part of the baseline, before rollout.

A workable model has four parts:

  • Configuration evidence — an exported, version-controlled record of the actual policy, so intent and deployment can be compared directly.
  • Operational evidence — log-derived proof the control is enforced day to day: sign-ins satisfying the expected grant control, or activation records confirming an eligible assignment went through activation rather than sitting permanently active.
  • Test evidence — a deliberate, periodic check that the control still blocks or flags what it should, run against a scoped test scenario rather than inferred from the absence of incidents.
  • Ownership and review frequency — who looks at this evidence, and how often. Evidence nobody reviews is indistinguishable from no evidence.

Define measurable pass/fail criteria alongside it — “100% of in-scope, non-emergency Global Administrator sign-ins satisfy phishing-resistant authentication strength, with zero unexplained exceptions this period” is testable; “admins use strong authentication” is not.

Treat exceptions as controlled engineering debt

Every baseline eventually meets a legitimate reason it can’t apply universally: a legacy application that can’t support modern authentication, an emergency access account by design, a vendor integration pending remediation. The mistake isn’t having exceptions — it’s letting them become permanent and undocumented, quietly turning “temporary risk acceptance” into “the actual baseline nobody wrote down.”

Treat every exception like debt with a repayment plan. Each one needs:

  • A named owner accountable for tracking it to resolution.
  • A business justification specific enough that a later reviewer can judge whether it still applies.
  • Compensating controls offsetting the missing preventive control while the exception stands.
  • An expiry or review date — without a forced re-evaluation point, exceptions tend to outlive the reason they were created.
  • Explicit residual risk — what could go wrong because this exception exists, for someone who wasn’t in the room when it was approved.

A baseline with three well-documented, actively reviewed exceptions is more trustworthy than one claiming zero that has never been audited closely enough to find them.

Worked example: privileged administrator access in Microsoft Entra

The following is a reference pattern for one narrow slice of a baseline — privileged directory role access — not a complete tenant configuration. Organizations differ enough in size, regulatory obligation, and tooling that no single configuration is universally correct; treat this as a starting shape, not a template to deploy unmodified.

Security objective. Reduce standing exposure of privileged Microsoft Entra directory roles (Global Administrator, Privileged Role Administrator) by requiring time-bound activation with strong authentication, and making activation observable.

Assumptions and prerequisites. The tenant holds Microsoft Entra ID P2 or Microsoft Entra ID Governance licensing, required for Privileged Identity Management per licensing fundamentals. Per Microsoft’s guidance on emergency access accounts, the reference pattern maintains at least two cloud-only emergency access accounts with permanent active Global Administrator assignments rather than PIM eligibility, excluded from any Conditional Access policy that would block or restrict their sign-in — while still subject to separate monitoring and regular validation rather than being exempt from oversight. Administrators are expected to have phishing-resistant authentication methods registered before rollout.

Preventive controls.

  • Sensitive role assignments are configured as eligible rather than permanently active in Microsoft Entra Privileged Identity Management, so access exists only after deliberate activation — see What is Privileged Identity Management?.
  • A Conditional Access policy requires the built-in Phishing-resistant MFA authentication strength for administrative sign-in, per Conditional Access authentication strengths — currently FIDO2 security keys, Windows Hello for Business or platform credentials, or multifactor certificate-based authentication.
  • PIM role settings require MFA on activation and cap the maximum activation duration, per Configure Microsoft Entra role settings in PIM; a Conditional Access authentication context can be configured within those role settings to apply an authentication-strength requirement specifically at activation, not just at sign-in.
  • Activation requires a documented justification and, for the most sensitive roles, approver sign-off rather than unattended self-service.

Detective controls.

  • Sign-in logs are reviewed for the maintained list of privileged accounts, or correlated with current privileged-role assignments, to check whether the expected Conditional Access policy and authentication strength were applied — a mismatch is a sign of a policy gap or unexpected exclusion.
  • Audit logs are reviewed for changes to the PIM settings and Conditional Access policies themselves, since a change to the control’s own configuration is as significant as a failed sign-in.
  • PIM activation history is reviewed periodically for frequency and justification quality, distinguishing routine use from anomalies such as unusually long or repeated same-day activations.

Evidence. Exported PIM and Conditional Access configuration; a recurring sign-in review scoped to the maintained privileged-account list or correlated with current role assignments; a scheduled test activation confirming expected prompts appear.

Acceptance tests. A test activation succeeds only with phishing-resistant authentication; an attempt using a weaker method cannot satisfy the authentication-strength requirement; a policy change produces a corresponding audit entry.

Exception handling. Emergency access accounts are documented separately with compensating controls rather than silently excluded. Any further exclusion needs the same owner, justification, compensating control, and review date described earlier, biased toward removing standing privileged access rather than keeping the exception indefinitely.

This pattern omits exact activation durations, approver counts, and a rollout plan — those depend on your organization’s size and maturity, and belong in your own record.

A reusable baseline record

The following template captures the attributes above in a compact, reusable form, one row per field — repeat the template per control for a program covering more than one. A mobile-friendly two-column layout keeps each field readable regardless of screen width.

Field Example
Control objective Reduce standing privileged directory role access
Scope Global Administrator, Privileged Role Administrator, excluding two documented emergency access accounts
Preventive control PIM eligible assignment + Conditional Access phishing-resistant authentication strength on activation
Detective control Sign-in review scoped to the maintained privileged-account list or correlated with current role assignments; audit log review for PIM/CA config changes
Evidence Exported policy config; scoped or correlated sign-in review; scheduled test activation
Acceptance criteria 100% of in-scope, non-emergency activations satisfy phishing-resistant strength; zero unexplained config changes per review period
Owner Identity security lead
Review frequency Monthly
Exception status 2 documented emergency access accounts, monitored separately and validated quarterly

Adapt the fields as needed, but keep evidence, owner, and review-frequency — the fields most often missing from checklist-style documentation, and the ones that make a baseline auditable rather than aspirational.

Conclusion: what to do next

Pick one control you already believe is “done” — MFA for admins is a common candidate — and fill in every field of the reusable record for it, honestly. Where you can’t, that’s the gap to close first.

  1. Write down the scope of that control, including exclusions you know about but haven’t documented.
  2. Separate its preventive control from its detective counterpart, if one exists.
  3. Define the evidence you’d need to prove it’s operating, and check whether you can produce it today.
  4. Convert any silent exclusion into a documented exception with an owner and a review date.

This article stayed at the level of the engineering framework rather than a full configuration walkthrough. Conditional Access design, privileged access strategy, identity risk signals, and evidence automation are each substantial enough for their own dedicated treatment, and future articles may go deeper into any of them as they’re written.

References