If you hold Business Premium, you already own this and probably have not built it.

These are the findings we produce most often, and both are invisible if you read the policy list rather than reading what sits outside it.

• Exclusions nobody can justify. Every conditional access deployment accumulates them: a service account excluded during an implementation because something broke, an exception for a colleague travelling, an application added to a bypass list for a migration. Each was reasonable and temporary. None was removed. The test is simple and uncomfortable: for every exclusion in every policy, can somebody state why it exists and when it should end.
• Break-glass accounts that were never tested. Microsoft guidance is to exclude emergency access accounts from conditional access so a misconfigured policy cannot lock every administrator out of the tenant. That is correct and it creates a permanently excluded, highly privileged account. If it is not monitored, and if nobody has ever verified it works, you have accepted the risk without gaining the benefit. Test it, alert on its use, and store its credentials properly.
• A third pattern worth naming: policies that grant rather than block where a block was intended. A policy requiring multifactor authentication for a group only protects members of that group, and group membership drifts. Targeting all users with a small set of deliberate exclusions is usually more robust than targeting a group that somebody has to remember to maintain.
• The practical starting point is not writing more policies. It is listing every exclusion across every existing policy, putting a name and a reason against each, and removing the ones nobody can defend. That exercise alone closes more real risk in most tenants than adding another rule.