Field note / identity and access

Enforcing a policy is not the same as guaranteeing an outcome.

MFA enforcement, Conditional Access policy, and delegated single sign-on administration can become a qualifiable recurring lane alongside Microsoft 365 or endpoint work - using the same inputs, outputs, and exclusions boundary this catalogue already uses elsewhere.

Coverage area

MFA enrollment and enforcement

Every user in scope has multi-factor authentication enabled and an agreed method.

Included pattern: Rolling out enrollment, enforcing the agreed method set, and following up on anyone who has not completed it.
Required inputs: Identity provider access, the agreed method policy, and a list of any approved temporary exemptions.
Explicit exclusions: Deciding which method is strong enough for a client's risk tolerance - that choice belongs to the client and partner.

Coverage area

Conditional Access policy administration

Sign-in is already gated by conditions such as location, device state, or risk level.

Included pattern: Building, maintaining, and documenting agreed sign-in conditions and what each policy blocks or allows.
Required inputs: A named risk tolerance, the users and applications in scope, and an agreed path for a policy that blocks a legitimate sign-in.
Explicit exclusions: A guarantee that a policy will never block a legitimate user or admit an illegitimate one.

Coverage area

Delegated SSO and app administration

Approved applications authenticate through the client's identity provider rather than a separate password.

Included pattern: Connecting approved applications, maintaining the delegated admin role for that connection, and retiring it when an app is decommissioned.
Required inputs: The application list in scope, who can approve a new connection, and the delegated role pattern for maintaining it.
Explicit exclusions: Vetting a new application's own security posture before it is approved - that due-diligence step happens earlier, with a different owner.

Coverage area

Access review and stale-account follow-up

Roles and sign-in exceptions accumulate in every tenant, whether or not anyone is watching.

Included pattern: A recurring check for accounts, roles, and exceptions that no longer match an active purpose, reported for a decision.
Required inputs: A review cadence and a named approver for removing what the review finds.
Explicit exclusions: Automatically revoking anything without a named decision owner signing off first.

Boundary table

Four questions that belong to qualification, not the public catalogue.

Question	Why the public bands cannot answer it	Where it gets answered
Which MFA method should be required?	Method choice trades convenience against risk tolerance - a tradeoff for the client and partner to make, not a public default.	Named in the identity policy record during qualification.
What happens when Conditional Access blocks a legitimate sign-in?	The right response depends on the policy's own logic and who holds authority to grant a temporary exception.	Written into the access plan's exception path.
Who approves connecting a new application by SSO?	Every new connection changes the tenant's attack surface slightly - approving that is a client-side risk decision.	Named in the delegated-role plan, not assumed by delivery.
Does this include identity threat detection or breach response?	Continuous detection and incident response is a different lane with its own scope and cost basis.	Scoped separately from routine administration.

See how a separately scoped monitoring and incident-response lane is qualified →

Representative pattern

Most identity lanes start narrower than the tenant.

Start with the identity provider already in place - commonly Microsoft Entra ID inside an existing Microsoft 365 tenant, though the same four questions apply to any provider.
Confirm MFA enrollment and enforce the agreed method for anyone not yet covered.
Add Conditional Access policies one condition at a time, with a named exception path agreed before enforcement, not after.
Bring delegated SSO administration in once the application list and an approval owner are named.
Put access review on a cadence so stale roles do not quietly accumulate between visits.

This is a process description, not a claim about a specific tenant's current configuration.

This is a different question from the delivery team's own tenant-role access - see how that access lifecycle is qualified →

The provider is not always Microsoft Entra ID - see what changes when a client runs Google Workspace →

Related decision

An identity role rarely removes itself.

The most common trigger for access review is not a calendar date - it is someone leaving. That is its own qualifiable lane.

Review the user lifecycle lane

Bring the policy shape, not tenant secrets.

Naming the MFA method, one Conditional Access condition, and the SSO applications already in use is enough for an initial fit review.

Discuss an identity and access lane