OpenIntuneBaseline for Intune policy imports

What OpenIntuneBaseline is designed to solve

OpenIntuneBaseline, or OIB, addresses the difficulty of establishing a known-good security posture for Windows devices managed through Microsoft Intune. The project began in 2021 because its author found existing baselines difficult from both administrative and user perspectives. It is aimed at Intune administrators, Windows administrators, security teams, and organizations that want a configurable foundation rather than a fixed compliance package.

The repository is not limited to Windows in its current structure. Its top-level entries include `WINDOWS/`, `WINDOWS365/`, `BYOD/`, and `MACOS/`, with each operating-system directory containing its own documentation, baseline JSON files, changelog information, and supporting material. The repository's primary language is listed as PowerShell, while the documented import workflows use exported baseline JSON files and external tooling.

The central design choice is deliberate incompleteness. The README calls OIB a starting point or foundation and says that it is not necessarily complete. It also disclaims responsibility for applying its settings in production tenants. That boundary matters. A baseline can reduce the initial work of assembling policies, but it cannot decide whether a setting matches a tenant's security model, device fleet, application compatibility requirements, or user support capacity.

Security reference material and policy interpretation

The initial Windows baseline was informed by security frameworks and platform guidance including NCSC Device Security Guidance, CIS Windows Benchmarks, ACSC Essential Eight, Intune Security Baselines for Windows, Edge, and Defender for Endpoint, and Microsoft Best Practice. OIB does not claim to reproduce those sources mechanically. The README says the project also adds user-experience improvements and reflects the author's experience implementing settings in customer environments, including the effect of policies on administrative manageability.

That interpretation is the project's main editorial distinction. Many security benchmarks are presented as rigid requirements even though they contain recommendations that organizations can adapt. OIB explicitly rejects a one-size-fits-all policy set because enterprise requirements differ. It also questions settings that enforce behavior a standard user cannot change or that duplicate policies carried over from much older Windows baselines.

The practical result is a baseline intended for review and adjustment, not an answer key. Organizations still need to decide which assignments apply to which device groups, whether a setting conflicts with existing configuration, and whether its impact on users is acceptable. The README does not document a compatibility matrix for every operating-system version, tenant configuration, or application, so that validation remains part of deployment work.

OIB Deployer, IntuneManagement, and native Intune import

OIB offers three documented import paths, and the choice determines both the control available to the administrator and the policy types that can be imported.

OIB Deployer is the project's dedicated deployment tool. The README says it supports platform-specific, granular deployment, checks for existing OIB policies in a tenant, and highlights missing or updated policies. It requires one application permission named `DeviceManagementConfiguration.ReadWrite.All`. The documentation states that a complete import can take less than a minute, but it does not provide the actual command line, deployment steps, or a code example in the repository excerpt.

IntuneManagement is the original deployment method according to the README. OIB baseline files are exported through that tool, and their import behavior follows the IntuneManagement documentation. Administrators can choose how much of the baseline to import, but they must set the correct `Root folder`, such as `WINDOWS` for the Windows platform or `Settings Catalog` for a policy type.

Native import uses Intune's built-in import and export functionality. Its documented limitation is substantial: it imports only Settings Catalog policies in the Device Configuration blade. Compliance and Endpoint Security policies are not included through this route. This makes native import suitable only when the deployment scope is limited to supported Settings Catalog content.

A first deployment workflow using the documented import paths

The repository excerpt does not provide installation commands, PowerShell syntax, or a complete import procedure. It directs users to OIB Deployer, IntuneManagement, or Microsoft's native Intune documentation. Therefore, the first use should begin by selecting the appropriate operating-system directory and understanding which policy files belong in that directory.

For an administrator using OIB Deployer, the documented starting sequence is to open the OIB Deployer service, grant the `DeviceManagementConfiguration.ReadWrite.All` application permission, select the relevant platform, and review the deployment selection before applying it. These are workflow descriptions derived from the README, not executable commands. The administrator should expect the tool to identify existing OIB policies and highlight missing or updated policies before the import.

For an IntuneManagement user, the relevant files are the exported baseline JSON files. Before importing, set the `Root folder` to the correct target, such as `WINDOWS` or `Settings Catalog`. The README says users may import as much or as little as they want, so a partial import is an intended workflow rather than an accidental limitation.

For native Intune import, confirm first that the required policies are Settings Catalog policies. If the intended deployment includes Compliance or Endpoint Security, the documented native route cannot cover it.

Versioned operating-system baselines and upgrade work

The repository uses a `Major.Minor` version format, with `Major.Minor.Patch` reserved for some bug fixes. Each operating system has a separate directory so that Windows, Windows 365, BYOD, and macOS content can evolve independently. The current Windows release listed in the README is `v4.0`, with a corresponding changelog and wiki page.

The release history includes `windows-v4.0` on 2026-09-30, `windows-v3.8` on 2026-05-08, and `windows-v3.7` on 2025-10-15. The repository's last push was on 2026-10-14, and it is not archived. These facts indicate recent repository activity, but they do not establish that every policy is continuously reviewed or that a new release is safe for a particular tenant.

An upgrade requires more than replacing JSON files. Existing assignments, profile names, changed settings, and the target device population can affect the result. The README does not document a rollback procedure, automated diff report, or compatibility promise for upgrades. Administrators should use the operating-system changelog and compare the intended release with existing tenant assignments before importing.

The repository also includes `releases.json`, a top-level `CHANGELOG.md`, and platform-specific changelogs. Those files are the relevant places to inspect when deciding whether an upgrade changes security controls, user experience, or policy structure.

Limitations and the cases where OIB is the wrong choice

The clearest limitation is that OIB is not a complete production baseline. The README directly warns against applying it without review and says no liability is assumed for use in production tenants. It also notes that a universal policy set is impossible because enterprise requirements differ.

Native import has a separate scope boundary. It cannot import every policy type supported by OIB. An organization whose design depends on Compliance or Endpoint Security policies needs OIB Deployer or an IntuneManagement-based workflow, rather than assuming that the native Intune import is equivalent.

OIB is also the wrong choice when an organization needs a formally certified compliance package, a contractual support commitment, or a deployment process with vendor accountability. Those properties are not claimed by the README. The project is community-driven and its stated purpose includes learning, development, and knowledge-sharing, so it should not be confused with an organization's approved security standard.

A further practical concern is administrative context. The README discusses user experience and administrative manageability, but it does not provide evidence about testing across every Windows edition, application, tenant setting, or migration path. A device organization should therefore review assignments in stages and document any exceptions rather than treating release version numbers as proof of fit.

Licence and adoption boundaries

The repository is licensed under `GPL-3.0`. That identifier establishes the stated licensing model for the project, but this review does not interpret the licence or provide legal advice. Organizations considering reuse or modification should review the repository's `LICENSE` file and assess their own compliance obligations.

OIB is most suitable for Intune administrators and security teams that want a documented community starting point, can interpret policy assignments, and are prepared to adapt settings to their environment. It is less suitable for organizations seeking an out-of-the-box production standard or assuming that a current release removes the need for local review.

The alternatives differ in approach. A Microsoft or CIS benchmark provides recommendations tied to a defined security framework and its own applicability rules. OIB instead combines framework-informed recommendations with user-experience and administrative considerations, then distributes them as versioned Intune files. A hand-built tenant configuration offers maximum local control but requires more internal design and maintenance. Before choosing OIB, verify the target platform directory, the import path, the required `DeviceManagementConfiguration.ReadWrite.All` permission for OIB Deployer, and whether native import covers the policy types you actually need.

Editorial conclusion

Adopt OpenIntuneBaseline if you want a community-maintained Intune policy starting point and are prepared to review every setting against your tenant. Do not treat it as a complete or universally safe production template. Verify first which platform policies are included, whether native import can cover your required policy types, and how your organization handles the required DeviceManagementConfiguration.ReadWrite.All permission.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. SkipToTheEndpoint/OpenIntuneBaseline on GitHub