A dated identity-security change needs an owner
Microsoft states that legacy user-risk and sign-in-risk policies configured in Microsoft Entra ID Protection retire on October 1, 2026. Organizations still using those controls should migrate them to Conditional Access. This is more than an interface change: an incomplete migration can remove automated responses to suspicious sign-ins or compromised accounts.
For Central Florida offices, schools, healthcare practices, construction firms, and professional organizations, the first management task is simple—identify who owns the tenant and require written evidence that the current configuration has been reviewed.
Understand the two risk signals
Sign-in risk represents the probability that a particular authentication attempt is not authorized by the identity owner. User risk represents the probability that the account itself is compromised. Microsoft Entra ID Protection evaluates signals and assigns low, medium, or high risk. Licensing affects the detail and automation available, so confirm the organization’s actual subscription before designing a policy.
Conditional Access can respond to sign-in risk by requiring an authentication strength, reauthentication, or blocking access. A user-risk policy can require secure remediation, force a password change in supported scenarios, or block the user until the risk is addressed.
Inventory before migration
Record every legacy risk policy, its included and excluded users, thresholds, access controls, and current enforcement status. Identify emergency-access accounts, service accounts, guests, and users without suitable MFA registration. Capture the last 30 days of risky-user and risky-sign-in activity so the team has a baseline for comparison.
Do not delete the old configuration before the replacement is documented and tested. The objective is continuity of protection, not merely clearing a portal warning.
Build the replacement in report-only mode
Microsoft’s current guidance recommends creating risk-based policies in Conditional Access and beginning in report-only mode. For sign-in risk, organizations commonly scope medium and high risk and require an appropriate authentication strength. For high user risk, the policy can require risk remediation. Emergency-access accounts should be handled according to Microsoft’s separate break-glass guidance so a policy does not eliminate the recovery path.
Review the report-only results for expected blocks, users who cannot satisfy the control, service dependencies, and false positives. Coordinate rollout timing with payroll, clinical schedules, school operations, field crews, and hurricane-continuity plans.
Prepare people and recovery paths
Users must have an authentication method registered before a sign-in-risk policy can successfully require MFA. Validate self-service password reset and help-desk identity-verification procedures. Tell employees what a legitimate remediation prompt looks like without teaching them to approve unexpected requests.
Keep at least two tested emergency-access accounts, monitor their use, and verify they remain available throughout the migration.
Evidence checklist
1. Export or document all legacy risk policies.
2. Confirm licensing and affected user populations.
3. Create replacement Conditional Access policies in report-only mode.
4. Review impact and remediate enrollment gaps.
5. Test with representative users and approved scenarios.
6. Confirm emergency-access exclusions and monitoring.
7. Enable the new policies in controlled stages.
8. Record approvals, results, exceptions, and rollback steps.
9. Verify risky-user and risky-sign-in reporting after enforcement.
The October 1 retirement creates a clear deadline. A short, evidenced migration now is safer than discovering after the cutoff that suspicious sign-ins no longer receive the intended response.