SC-300 common mistakes
SC-300 · Understand the traps and how to avoid them.
Enabling self-service password reset for all users and assuming hybrid (synced) accounts can reset their passwords, without ever verifying that password writeback was turned on in Microsoft Entra Connect.
SSPR configuration in the Entra portal looks complete and the user can register methods successfully, so the gap only surfaces when a synced user actually submits a reset and receives 'Your organization's password cannot be reset at this time' or the reset silently fails to reach on-premises AD.
What to do instead
Confirm password writeback is enabled in the Entra Connect wizard (or via Set-ADSyncAADPasswordResetConfiguration on cloud sync agents), then validate end-to-end with a test synced user rather than relying on the portal's registration report.
Building a dynamic group rule that references device attributes (for example device.deviceOSType -eq "Windows") and applying it to users, expecting all Windows users to become members.
Dynamic user groups and dynamic device groups are separate object types with different attribute sets; a rule written against the wrong member type either fails validation or simply never matches anything, and the licensing policy attached to the group then silently applies to nobody.
What to do instead
Decide the member type first, then use only attributes valid for it - user properties (department, jobTitle, user.accountEnabled) for user groups, device properties for device groups - and check the group's processing status plus the returned members before attaching licenses or policies.
Assigning a license directly to a user and also through a group, then expecting removing the user from the group to remove access to the service.
Direct and group-based assignments are separate sources of the same product licence; the service plan stays enabled as long as any source still grants it, so the removal appears to do nothing and the tenant accumulates confusing licence-count mismatches.
What to do instead
Standardise on group-based licensing, remove the direct assignment for that product before or at the same time as removing group membership, and use the group's reprocessing plus the user's licence blade to confirm no other source is still supplying the plan.
Responding to a compromised account by setting Block sign-in on the user and assuming all active sessions and access tokens are immediately invalidated.
Blocking sign-in prevents new authentication but does not by itself terminate refresh tokens or existing access tokens, so an attacker with a live session can keep working until token lifetime expiry - which is why the incident appears unresolved after the block.
What to do instead
Use Revoke sessions in the user's profile (or a Conditional Access 'Revoke sessions' control / risk-based policy) together with the block, confirm the sign-in and audit logs show token revocation, and shorten token lifetimes where continuous access evaluation is not enabled.
Deploying a new Conditional Access policy in Report-only mode to 'test' it, observing no impact on users, and concluding the policy is correctly scoped and will enforce as intended.
Report-only mode never blocks or challenges, so a policy that excludes the wrong group, targets the wrong cloud app, or fails to exclude emergency access accounts looks perfectly healthy in the sign-in log while producing zero real protection.
What to do instead
Validate with the What If tool and the report-only sign-in log details (which policies would have applied and which controls would have fired), explicitly exclude at least two break-glass accounts from every policy, then move the policy to On and re-test with a pilot group.
Adding office egress IP ranges to the legacy per-user MFA 'trusted IPs' settings and expecting Conditional Access to treat those locations as trusted (or expecting a named location to exempt users from legacy MFA).
The legacy MFA trusted IP list and Conditional Access named locations are two different stores; Conditional Access evaluates named locations only, so the exemption never triggers and users are still prompted - or the reverse, users are silently bypassed in one system only.
What to do instead
Configure named locations under Protection > Conditional Access > Named locations, mark the location as trusted if that is the intent, and reference the named location in the policy's Conditions > Locations include/exclude; leave the legacy trusted IP list out of the design.
Creating a managed identity and then searching App registrations for it to add redirect URIs or credentials, or assuming a system-assigned identity object survives the resource being deleted and recreated.
Managed identities surface as service principals (enterprise applications), not app registrations, and a system-assigned identity's lifecycle is tied to its parent resource - deleting the VM or function app destroys the identity and its role assignments, breaking the workload on redeploy.
What to do instead
Look for the identity under Enterprise applications (object type 'Managed identity'); choose a user-assigned managed identity where the identity must outlive the resource or be shared, and grant it the role assignment once at a stable scope.
Giving a workload a client secret for a CI/CD pipeline or external SaaS integration, and controlling that workload's access only with Conditional Access policies written for interactive users.
Secrets expire, get committed to pipelines, and are not tied to the workload's identity, while Conditional Access for workload identities is a separate policy surface with its own licensing - so the workload is either ungoverned or left with a policy that never evaluates.
What to do instead
Use workload identity federation with a federated credential (subject/issuer/audience matched to the pipeline) instead of a secret, and if Conditional Access for workload identities is required, confirm the tenant holds the corresponding workload identities licence before designing location or risk-based blocking.
Making a user a permanent Active Global Reader (or any privileged role) directly in the Entra roles blade, then expecting PIM settings such as approval, MFA on activation, justification, and maximum duration to apply.
PIM activation settings govern eligible assignments and activations, not direct permanent assignments; a direct assignment bypasses the entire activation flow and grants standing access that PIM reports and alerts on but never restricts.
What to do instead
Create the assignment as Eligible through PIM (or make the user eligible for membership of a role-assignable group created with IsAssignableToRole and assign the role to that group), remove standing direct assignments, and rely on access reviews plus PIM alerts to detect out-of-band assignments.
Running an access review, recording 'Deny' decisions for inactive guests, and assuming the guests lost access, or setting up an access package for partners while trying to enforce re-attestation through group settings instead of a review.
Review decisions only take effect when 'Auto apply results' is enabled (or when the reviewer's decisions are manually applied at completion); and entitlement management, group membership, PIM, and access reviews are complementary controls - access packages govern assignment and expiry but do not re-certify by themselves.
What to do instead
Enable auto-apply on the review series (or apply results explicitly on completion) and verify with the audit log that membership was removed, and design governance as a chain: access package for request/approval/expiry, plus a recurring access review targeting that package or group for re-attestation.