inforcer Techtalk - Episode 1: Rolling out Essential Eight with inforcer
Essential 8 compliance across multiple tenants is challenging. My name is Nathan, and I’m from inforcer. Let me show you how Essential 8 compliance can be delivered simply and consistently. The Essential 8 consists of eight mitigation strategies, each with a number of underlying controls. These include application patching, operating system patching, restriction of administrative privileges, multi-factor authentication, application control, Microsoft Office macro restrictions, user application hardening, and regular backups. As an MSP operating in a multi-tenant environment, the challenge is how to standardize and roll out these controls effectively across all customers.
Using inforcer, the first step is to assess where a customer currently sits against the Essential 8 framework. We start by running an Essential 8 maturity level one assessment against the tenant. In this example, we assess the Nakatomi Corporation and receive an overall compliance score of 59 percent, with 29 controls passing and 20 failing. This provides a clear baseline and highlights where remediation is required. The assessment report can be exported and shared with the customer, clearly showing each check, the reason for failure, and the associated ISM controls.
Once approval is provided to proceed with remediation, inforcer makes alignment straightforward. We move to the alignment section and select our master Essential 8 baseline, then apply it to the customer tenant. The environment is broken down into clear categories, including recommended from baseline, unaccepted deviations, aligned policies, existing customer policies, and accepted deviations. The first focus is on policies recommended from the baseline. In this case, we identify missing multi-factor authentication policies for all users and administrators.
By expanding the policy details, we can view its configuration, see how it differs from the baseline, and confirm it should be aligned. Renaming the policy to match the baseline immediately updates the customer’s configuration. The policy then appears as an unaccepted deviation, allowing us to review the remaining differences. We align the policy fully to the known-good baseline state, confirm the required settings, and submit the change. The deployment runs automatically and completes without manual intervention. Once deployed, the policy moves into the aligned state.
Repeating this process across all remaining items brings the tenant into full alignment. At this point, the customer reaches 100 percent alignment with the Essential 8 maturity level one baseline. We then rerun the assessment to validate the outcome. The reassessment confirms 100 percent compliance, and the updated report can be exported and shared with the customer as formal evidence.
This approach allows MSPs to standardize Essential 8 compliance across multiple tenants efficiently, delivering consistent security outcomes, continuous proof, and repeatable governance at scale. Thank you for watching.
inforcer Techtalk - Episode 2: Partner Centre Onboarding
Hello everyone and welcome to another inforcer tech talk. Today we’re going through Partner Center and showing how to set up GDAP relationships, security groups, and how Inforcer helps manage all of this, including onboarding tenants through Partner Center. Onboarding through Partner Center is the simplest and most effective approach, so let’s get started.
To successfully set up Partner Center, there are three or four core requirements. For an initial Partner Center setup with Inforcer, you need Global Administrator or at least Application Administrator permissions in your MSP tenant. You also need Admin Agent access in Partner Center, as the account performing onboarding must be a member of the Admin Agents group. A Partner Center admin relationship with the customer is required, with a minimum of eleven delegated roles assigned. Finally, you need a security group containing the users who will onboard tenants, with those roles applied.
The eleven required roles are Application Administrator, Directory Writer, Exchange Administrator, Groups Administrator, Help Desk Administrator, Intune Administrator, Security Administrator, SharePoint Administrator, Teams Administrator, and User Administrator. With those roles confirmed, we can use Inforcer to configure everything needed to get Partner Center running.
Setting up Partner Center through Inforcer is straightforward. Navigate to Tenants and select Partner Center Manager. This prompts authentication using an account that has Application Administrator permissions and membership in the Admin Agents group. Inforcer then loads your tenants. In this example, we’re working with a tenant called Nathan GDAP Test. At this stage, the tenant has no GDAP configuration, no assigned groups, auto-renewal is disabled, and there are no eligible onboarders. Only the basic customer relationship exists, so we begin remediation.
First, we create an administrative relationship, defining a relationship name, duration of 730 days, and role selection. Inforcer provides predefined options, including the required eleven roles, recommended balanced roles, or all roles. In this case, all roles except Global Administrator are selected for flexibility, while only required roles are later assigned to the security group. Auto-extension is enabled, and the relationship is created.
The relationship then requires customer approval. The provided approval link is opened in the customer tenant, where the MSP information is reviewed, the customer agreement is acknowledged, and the delegated roles are approved. Once accepted, Inforcer updates the tenant status after synchronization.
With the relationship active, the next step is assigning a security group. Inforcer detects existing groups or allows creation of a new one. A pre-created GDAP onboarding group is selected and assigned to the tenant. After Microsoft completes synchronization, the group becomes active in Partner Center with pending status until verification completes.
Users onboarding tenants into Inforcer must be members of this assigned security group. Once the correct user is added to the group and synchronization completes, Inforcer identifies eligible onboarders. At this point, onboarding the tenant is simply a matter of selecting the onboard option, assigning a license, optionally applying tags and baselines, and submitting the request.
The onboarding process completes automatically, and the tenant is successfully onboarded into Inforcer using Partner Center. This demonstrates how Partner Center and Inforcer work together to simplify GDAP setup, role assignment, and tenant onboarding at scale. For further details, refer to the available documentation, and thank you for watching.
inforcer Techtalk - Episode 3: Top 5 Policy Misconfigurations
Hello everyone and welcome to another inforcer tech talk. Today we’re covering the five most common policy misconfigurations we see across Microsoft environments. These issues typically appear in Entra ID, Defender for Office, Intune, and related services, and are usually caused by misunderstandings in configuration rather than missing technology. This session highlights those pitfalls and explains how to avoid creating security gaps.
The first policy area we review is geographic blocking in Entra ID. Geo-blocking is widely used but frequently misconfigured. The correct approach begins with named locations. For example, creating a named location for Australia allows the creation of a conditional access policy that requires MFA for users signing in from that country. When tested using the What If tool with an Australian IP address, MFA is enforced correctly. However, when testing with an IP address from another country such as Angola, the policy does not apply. If no other conditional access policies exist, this results in users signing in with no MFA enforcement.
To close this gap, an inverse policy must be created. A second named location is configured to include all countries except Australia, including unknown locations. A new conditional access policy then blocks access from those locations. When tested again, access is blocked for non-Australian locations while Australian access remains allowed with MFA. This completes a properly configured geo-blocking setup. That said, Microsoft no longer recommends geo-blocking as a standalone security control due to easy circumvention using VPNs. A stronger and more scalable approach is requiring compliant devices through Intune-based conditional access, which follows the device rather than the location and reduces administrative overhead.
The second common issue concerns macro blocking in Microsoft Office. While many security frameworks require strict macro controls, they cannot be enforced using Microsoft 365 Apps for Business, which is included with Business Premium. Macro enforcement is only supported with Microsoft 365 Apps for Enterprise, available through an add-on or E3/E5 licensing. Although Intune allows macro policies to be created and deployed, they will not apply to the Business version of Office and may briefly apply before reverting. This is not a policy misconfiguration but a licensing limitation that is often overlooked, particularly in regions where frameworks such as Essential Eight mandate macro controls.
The third area involves Defender for Office 365 policies. Microsoft-provisioned tenants include default policies that are loosely configured and do not meet Secure Score requirements. These default policies often have critical protections disabled, including user impersonation protection, domain impersonation protection, mailbox intelligence, spoofing protection, and aggressive phishing thresholds. Relying on default policies leaves mail environments underprotected. Best practice is to create custom Defender for Office policies that explicitly enable these protections. This also allows standardization and automation, as default policies cannot be modified, deleted, or managed through Inforcer.
The fourth category is Intune compliance policies. Many organisations only configure a minimum OS version, but effective compliance policies go further. A strong Windows compliance policy should include Secure Boot enforcement, BitLocker requirements, Defender anti-malware enabled with real-time protection, and a defined device risk score threshold. On their own, compliance policies only mark devices as compliant or non-compliant. Their real value comes when combined with conditional access. By requiring compliant devices and MFA, access is restricted to managed and secured endpoints only. This prevents sign-ins from unmanaged personal devices and aligns with Microsoft’s Zero Trust recommendations. Inforcer can standardize and deploy both compliance and conditional access policies across all tenants to maintain a consistent security posture.
The final area is SharePoint and OneDrive sharing configuration. By default, Microsoft allows anonymous sharing links, which is the least secure configuration. Best practice is to restrict sharing to new and existing guests who must authenticate or verify their identity. Additional controls such as guest access expiry, default view-only permissions, and restrictions on external sharing further reduce risk. These settings apply tenant-wide, while individual sites can be configured with stricter controls where required, but never more permissive than the tenant default. For environments handling sensitive or regulated data, particularly when using Purview classification, strict sharing controls are essential.
These five areas represent the most common policy-related security gaps seen across Microsoft 365 environments. Addressing them consistently creates a significantly stronger baseline security posture. If you have questions about these configurations or want help standardising them across tenants, reach out through the Inforcer platform or your account manager. Thank you for watching, and I hope this has been useful.
Episode 1: Rolling out Essential Eight with inforcer
Episode 2: Partner Centre Onboarding
