From Finding to Fix: Acting on a Microsoft 365 Security Report

A Microsoft 365 security report is only useful if each finding tells you how to fix it safely. Work through findings in order of risk, test every Conditional Access change in report-only mode first, and keep an emergency access account excluded before anything is switched on.

Most security reviews end the same way: a long list of failed checks and a polite suggestion to address them. The hard part, deciding what to change, where, and how to do it without locking staff out, is left to whoever reads the report. This article covers how Posturis, the Microsoft 365 security posture assessment we built ourselves, now carries each finding through to the fix, and how to act on any posture report safely.

The short answer

Treat a security report as a work plan, not a verdict. Each finding should say what was found, why it matters, and the change that would close it. Changes to sign-in rules carry the most risk, so they should start in Conditional Access report-only mode, where Microsoft evaluates a policy at every sign-in without enforcing it. Keep at least one emergency access account excluded from any policy that could block sign-in. Then switch the policy on once the sign-in logs show it behaves as expected.

Why a list of failures stalls

A failed check on its own rarely gets fixed quickly. The administrator who reads it has to research the setting, work out whether the tenant is licensed for it, and judge what might break. In a small IT team that work competes with everything else, so findings sit in a spreadsheet until the next review finds them again.

Sign-in changes are where this hurts most. A Conditional Access policy that requires a compliant device or blocks legacy authentication is exactly the kind of control a review recommends, and exactly the kind that can stop a whole office signing in if it goes on untested. Understandably, teams hesitate.

What each Posturis finding now carries

Posturis is read-only. It evaluates 46 controls across identity and access, Identity Protection, Intune device management, email and collaboration, SharePoint and OneDrive sharing, and app and tenant governance. It changes nothing in the tenant. The decisions and the changes stay with your administrator or your Microsoft partner.

What has changed is how much help comes with each result. Every finding now includes:

• What was found. The setting as it stands, in plain language.
• Why it matters. The risk it creates, and the frameworks it bears on, such as ISO/IEC 27001, NIST CSF and the CIS Microsoft 365 Foundations Benchmark.
• Step-by-step remediation guidance. Where to make the change and what to set, written so an administrator can follow it.
• A safe starting point for sign-in changes. Suggested Conditional Access policies are written in report-only mode, with an emergency access account excluded.

Controls that need a licence you do not hold are still marked Not applicable rather than failed, so the guidance you see is for changes you can actually make today. Our article on what is new in Posturis covers that feature and the monthly review.

Report-only first: testing Conditional Access safely

Microsoft built report-only mode for this problem. According to Microsoft Learn, a policy in report-only mode is evaluated during sign-in but not enforced, so users are not prompted for multifactor authentication or other controls, while the sign-in logs record what the policy would have done. Administrators review that result and then move the policy from report-only to on.

In practice that gives you a rehearsal:

• You see which users and applications the policy would affect.
• You find the account or device that would have been blocked, before it is.
• You can run a new policy alongside the ones already enforced and compare.

One limit worth knowing: Microsoft notes that policies scoped to user actions, such as registering security information, cannot be evaluated in report-only mode. Those need more careful planning.

Keep a way back in: emergency access accounts

Microsoft recommends two or more emergency access accounts: cloud-only accounts, not tied to one person, used only when normal administrator access fails. Its guidance is to exclude them from any Conditional Access policy that blocks or restricts sign-in, and to test regularly, quarterly for example, that they can still sign in.

Report-only policies cannot block anyone, so strictly the exclusion matters at the moment a policy is switched on. That is why Posturis suggests it from the start. When the administrator moves the policy to on, the exclusion is already in place, and a mistake in the policy cannot lock every administrator out of the tenant. If your tenant has no emergency access accounts at all, that is a finding in its own right. Our article on cutting back Global Administrators covers how they fit alongside a smaller set of admin roles.

Deeper identity and device checks, and a CIS view

The checks behind the guidance have also gone deeper. Conditional Access checks look at named locations, compliant or managed device requirements, phishing-resistant authentication strength, and sign-in and user risk policies. Intune checks confirm that compliance policies exist, are assigned, and flag devices out of compliance. Identity Protection checks look at accounts flagged at risk and whether risky sign-ins are reviewed, where the tenant is licensed for them.

Results can also be read against the CIS Microsoft 365 Foundations Benchmark, a widely used, community-built baseline. That helps when a client questionnaire or an auditor asks how your configuration compares with a recognised standard. It is evidence for that conversation, not a certification.

Frequently asked questions

Does Posturis make changes to our Microsoft 365 tenant?

No. Posturis is read-only. It suggests changes with step-by-step guidance, and your administrator or Microsoft partner decides whether and when to make them.

What is Conditional Access report-only mode?

It is a policy state in Microsoft Entra ID where a policy is evaluated at every sign-in but not enforced. The sign-in logs show what would have happened, so you can check the impact before switching the policy on.

Why exclude an emergency access account from Conditional Access?

So that a faulty policy cannot lock every administrator out. Microsoft recommends excluding emergency access accounts from any policy that blocks or restricts sign-in, and testing that they still work.

How long should a policy stay in report-only mode?

Long enough to see normal working patterns, including staff who travel, work from home or use older devices. For most small organisations that means at least a full working week of sign-ins.

Does following the guidance make us compliant with ISO 27001 or the CIS benchmark?

No single report does that. Posturis gives you control evidence and a clear path to close gaps. Certification and audit opinions come from an accredited body or auditor.

Where to start

Whether the report comes from Posturis or another review, this order keeps risk low:

1. Confirm your emergency access accounts. Make sure two exist, are cloud-only and can sign in.
2. Sort findings by risk and effort. Quick, low-risk changes such as email settings go first.
3. Give each finding an owner. One named person per change, with a date.
4. Create sign-in changes in report-only mode. Exclude the emergency access accounts from the start.
5. Read the sign-in logs. Look for anyone the policy would have blocked, and adjust.
6. Switch on, then re-assess. Run the assessment again so the closed finding shows in your evidence.
7. Record what you accept. Where you choose not to act, note why and who approved it.

Posturis is available by arrangement.

Onprem2Cloud IT Solutions Co. is a Microsoft CSP partner based in Muntinlupa City, Metro Manila. See Posturis alongside our other in-house software on the software page, or contact us to arrange a run.