Configured vs inforced vs Effective

Tim

Hello everyone. Hopefully you can all hear me and see my screen. I can see the thumbs up coming through, so I am going to assume we are good to go. We will give everyone one more minute to join and then we will get started.

Welcome, and thank you for joining another webinar in the series. Some of you have probably been on a few of these already, so you may be tired of my voice by the end of it, but we are trying to build out useful content for the MSP community, existing partners and prospective customers.

The aim is to help you focus on where we can go in 2026, how we move forward, and how we collectively invest in providing the best possible services to the customers we support. Fundamentally, we make our money and earn our living by delivering a high-quality, white-glove service to the businesses we support. To do that, we have to make sure we are leveraging the tools we use properly, while keeping them measured, updated, managed and supported.

For many of you, inforcer is one of those tools, whether you are already using it or looking to use it as a prospect. Today’s webinar is focused on configuration, enforcement — with an E, although there is obviously a play on words with inforcer — and effectiveness. The question is how we make sure we continue to be effective in the platform.

As part of the defend, govern, improve series, this session focuses on configured, enforced and effective. It looks at the differences we focus on when we start implementations. These areas are part of the frameworks that many customers align to.

Towards the end of March or early April, we will be creating a new webinar series called Comply or Cry. I am announcing it now. It will be about taming Microsoft 365 by leveraging recommended guidance such as CIS controls, as well as regulations like NIS and DORA. We will focus on why those frameworks are important, how they are measured against Microsoft, and where you can use inforcer features such as policy tagging and bespoke baselines to make the most of the frameworks you need to follow.

That is also where we commercialise products like inforcer. We want to make sure we are generating commercial gain for the businesses we support and for our own businesses. This session is designed to give you food for thought. I want you to leave with a clear view of how three pillars of service can work together efficiently: configuration, enforcement and effectiveness.

Let’s start with the three levels of maturity that apply to baselines and frameworks. The first is configuration. Does the policy exist in the environment? Is the setting enabled? Does a dashboard give us a green indicator? That is Secure Score and the alignment view you see in inforcer.

Most people on this call probably do configuration very well. You create the policy, make sure it exists, turn it on, and make sure there is a green tick for something like Cyber Essentials. Then you move on because there is another project to work on. The question is how we make sure those preparations are actually enforced.

That is the next step in the defend, govern, improve journey: governance and enforcement. We have the configuration and the baseline, but now we need to apply the controls that make sure it is enforced. We already do this with things like conditional access and MFA. The enforcement of MFA is usually in place for customers, but we also need to hold ourselves accountable for enforcing that conditional access policy.

How do we make sure nobody has been added to an exclusion group? How do we make sure the scope is clear, defined and documented? These are governance tasks, and they are part of enforcement. We cannot leave the journey at configured. A one-time single pane of glass view of configuration is useful, but the next step is enforcement, and that means drift detection.

If someone makes a change to a configuration policy, drift detection helps identify that. We are also working towards drift detection for specific exclusions to groups, which is exciting. We also need to make sure people are not bypassing processes. We document, measure, align and alert, but the next step is effectiveness.

Effectiveness is about demonstrating that companies are really driving the process and proving the value of the work being done. It is evidence-based. We need to show customers that we are implementing the configuration, enforcing it, and providing proof of value.

That is the maturity journey inforcer needs to drive to you, and you need to drive to your customers. We do not just sit at configuration. We do not just sit at reactive services. We add a proactive measure by enforcing the policies we implement, then prove that work through reports and measurements.

All three pillars are available within inforcer. Configuration is delivered through the best-practice baseline. Enforcement is measured through drift detection, clearly defined scopes and ongoing alignment checks. Effectiveness comes through evidence: alignment reports, the assessment engine and ongoing proactive reporting for the customer.

Let’s look more closely at configuration. Configuration can create the illusion of completion. It is a one-time deployment: we get our best practice, apply it, see a green tick and feel finished. That green tick is useful, but it can make us think the work is done when it is not.

We go through the implementation, measure progress, take policies through low, medium and high-impact tags, make sure they are 100% configured, provide an alignment report and then move to the next project. Tooling activity often rewards the current state. Configuration becomes a green tick exercise, and then things start to stagnate.

Project engineers naturally move on to the next thing. I was always good at getting configuration done and reaching 99%, but then the next big project would come in and I would get distracted. That is where oversight appears.

Configured answers the question: did we turn it on? It does not answer who it actually protects. That is the next step: enforcement. After configuration, we need to demonstrate who is impacted.

Microsoft guidance often recommends assigning critical policies to all users and all devices, using exclusions where there is a specific reason rather than assigning policies only to narrow groups. Critical configured policies should generally apply broadly, with exclusions added only for specific platforms or services that need them. If we create a policy and assign it only to a specific group, we may fail to account for enforcement properly.

Configuration quietly fails in several places. The first is partial scope coverage. We may not be applying policies or controls to all relevant users. That creates a critical gap. At the end of every project, lessons learned should include scope coverage. Does the implementation cover everyone it is meant to cover? Are there any critical gaps?

Another area is legacy authentication pathways. This is especially relevant for conditional access. Most companies will implement all users for MFA, require device compliance and block legacy authentication. But do we go a step further and block platforms that are not in use? If you are not using Linux, should there be a policy that blocks Linux devices? It is worth testing whether there are authentication pathways that do not require MFA or that allow access in ways you did not expect.

Temporary exclusions are another common problem. They get added for convenience and then become permanent. Break glass accounts are a good example. We often create a YubiKey for break glass access but then exclude that account from MFA-related policies, which can make the YubiKey redundant. Temporary exclusions often become permanent fixtures because we forget them, especially when a project ends and the handover to the customer or service desk is imperfect.

Service accounts are another area that can be overlooked. In larger or more mature environments, customers may have many SaaS applications and somewhere in that estate there may be a service account or non-human identity that falls outside the user scope. That still needs to be measured, identified and documented. If it is permanently out of scope, it should be added to a risk register.

Break glass access should also be reviewed. Emergency accounts exist for a reason, but they should be tested, validated and reviewed. That can include checking access, resetting passwords, storing them correctly, testing YubiKeys and making sure the process works. Where possible, we should look to enforce policies against break glass accounts, or create specific conditional access policies for them. For example, we may require a compliant Windows device and MFA using a YubiKey. The key is to make sure break glass access is secure, tested and documented.

The second level is enforcement. This is where reality starts. We need to stop finishing at configuration and start completing enforcement. Controls move from the theoretical state of being configured to the operational state of actually being measured and enforced. We need to make sure the right people are in the right scenarios with no invisible side doors.

What does enforced really mean? First, the right users. The controls we implement need to affect everyone in the intended scope. That may be the whole organisation, or it may be a defined subset such as the executive leadership team. There cannot be silent exceptions or gaps.

Second, the right devices. We need to make sure only the devices we have agreed can access the platform. If the organisation uses Macs, we should be looking at Apple Business Manager where possible. If the environment is Windows-only, we should block other device platforms that should not be in use. Blocking Linux devices or Android tablets that are not approved is one area people often forget. That is an additional enforcement layer that can easily be missed after configuration.

Third, the right scenarios. Policies need to be context-aware, adapted to risk and designed in a way that avoids bypass opportunities. When building a scope of works, professional services deployment or baseline in inforcer, we need to ask whether we are creating gaps.

This also applies to naming conventions and baseline management. My advice is not to create naming conventions with too many people in the room, because it can take months instead of hours. Create a practical best-practice naming convention and move forward. The important thing is that the process is clear and usable.

Fourth, there should be no side doors or backdoor entry. Legacy protocols need to be turned off, legacy authentication should be blocked without inappropriate exclusions, and workarounds should be identified and closed. When building a baseline, focus on users, devices, scenarios and side doors. Check the gaps that exist.

There are several common enforcement gaps. Exclusion lists grow organically over time. They may include a CEO or senior user with an old phone who has not adopted Microsoft Authenticator. emergency access accounts are another common gap. We can often use YubiKeys rather than permanently excluding break glass accounts, but they need to be tested regularly.

Bring-your-own-device scenarios can also slip around device trust requirements. Have we configured Autopilot correctly to block personal enrolment where that is appropriate? In some industries, such as marketing, contractors may need to enrol personal devices, and that may be legitimate. The point is that it needs to be deliberate, documented and measured. Legacy protocols are another common gap. Role changes are also a risk because they do not always trigger policy reassessment. Dynamic groups are powerful, but if role or attribute changes cause users to move into or out of groups, we need to make sure that does not unintentionally bypass controls.

The third level is effectiveness. This is the maturity line we should always aim for. Effectiveness is not about perfection; it is about resilience in the face of inevitable change. That is the statement I want you to walk away with. It is never about creating a perfect environment. It is about creating a secure environment that stays resilient when change happens.

A baseline does not need to be perfect or unique. It needs to be secure. Effective means the environment survives change. It also needs to fail loudly. When something goes wrong, we need to be alerted. MSPs are excellent at being reactive, so when something changes, it needs to raise an alert clearly enough that we can act.

That is where alignment and drift detection come in. We can set up measurements on alignment and drift detection reports. We can be alerted to alignment score changes. When these three pillars are working together, tickets can be raised when someone makes a change or something breaks in the environment.

Effectiveness also means evidence without effort. We need proof in the controls. We need to demonstrate the value we deliver to customers, and that evidence needs to be reliable.

I have more slides, but I would rather move into a live demo. Welcome to my demo environment. It is a small set of customers, although it looks bigger because I have created many baselines. I want to talk through some basic principles I use with inforcer that help measure configured, enforced and effective.

These are the three pillars I work towards whenever I build an inforcer environment. The goal is day-one value and ongoing measurement. Most organisations take on inforcer because they want one great baseline that they can deploy to new customers. But we need to take that one step further. We need to enforce it and prove that we are being effective.

The first step starts with the default baseline we create. In my demo environment, I have policies built in Microsoft 365. Once those policies are built, the area I find most valuable is policy tags.

Policy tags help you make sure you are not only configuring an environment but also enforcing it and proving it is effective. It starts with building a strong policy tag model. Once you have built your best practice, take policies from existing customers, deploy them to a baseline tenant and then create a sensible model for policy tags.

For example, I may tag all Defender for Office policies with Defender for Office. If they are bespoke, I may add another tag for low impact, medium impact, high impact, a phased approach or a security model. I also want to tag policies that include variables. If I am deploying Autopilot and device rename, I want to know which policies have variables associated with them. If it is an Android project, I want to know that the Android policies are in place.

Tag as many policies as you can in your baseline because it gives you many opportunities to prove value to a customer. If you have best-practice Android policies, Defender for Office policies or framework-specific policies, tags help you report on them.

When creating a bespoke report, you can select a tag such as Defender for Office and show a customer that there are eight policies and they are aligned to all eight. The alignment report also shows the policy tags associated with each policy. You could create tags for DORA, CIS libraries or Cyber Essentials and demonstrate that the customer is aligned to all the relevant policies for that regulatory or framework requirement.

Policy tags therefore help prove value and demonstrate effectiveness when deploying tools like inforcer.

The other area I want to talk about is enforcement, and that starts with alerting. Once you have built your best practice, created the naming convention and started measuring customers against the baseline, you need an ongoing enforcement journey. Drift detection and alerts are part of that.

Policy change notifications are one of the most important alerts in the environment. They detect changes made to policies and support ongoing governance of the enforced policies you have put in place.

Another useful alert is alignment score change monitoring. If a customer was 100% aligned, or 95% aligned, and then drops below a defined threshold, you need to know. If alignment is part of the effective approach you deliver, alignment score becomes central to keeping customers aligned to your best practice.

You need alerts to prove that you are measuring changes. There can be an alert showing the drop, followed by evidence that the issue has been counteracted and the customer is aligned again. Sometimes alignment scores change because you have proactively created new policies or improved the environment. Either way, you measure it and report against it.

There are many other alerts as well, such as Apple MDM certificate alerts. Alerts help start the effective journey. When we build a good practice environment and an enforced practice, we move from theory into operation. Then we need to prove effectiveness through alerts, assessments and alignment reports.

Assessments support that effectiveness. If your customers do not have the right naming convention, that does not stop you from measuring whether the environment is effective. You can use tenant assessments and build custom assessments. In my example, I created an assessment with checks specific to a business and then ran those checks against customer environments.

These reports are executive-friendly. When you are bringing a solution to a group of businesses, or speaking to a prospect, you need to demonstrate what you consider best practice and what a resilient environment looks like. The assessment becomes a configured set of checks, an enforced set of expectations and a report that proves whether you can be effective and resilient when delivering best practice.

When prospecting, an assessment report proves that your business has three tiers of maturity. You start with configuration, then show that it is enforced, and finally prove that it is effective. The report starts that conversation. If you win the business, you then take the customer through the three-tier maturity journey of configuration, enforcement and effectiveness.

To wrap up, I want you to walk away with three foundations. Configured is the foundation. It is necessary, but it is not enough on its own. Enforcement is where we hold ourselves accountable for what we have configured and make sure the controls actually protect the environment. Effective is where confidence is earned: proving that the controls survive change, remain resilient and meet the measurements we promise customers.

That is the core message. If you have questions, please reach out to the team. If you are a prospect, book a demo. If you are already a customer and have more questions, reach out to your partner success manager and we can go through the detail or arrange sessions.

If you want more content, whether about the platform or Microsoft more generally, reach out to the partner success team and suggest webinars that would add value. I would love to do more sessions this year to help enhance your knowledge, give you more information and help you move forward.

Thank you very much. Have a wonderful rest of the day, and speak to you soon.