[Feature] - Split up "Win - OIB - SC - Microsoft Office - U - Security" into more granular policies

[xenadmin]

Is your feature request related to a problem? Please describe.

We are a German IT managed service provider (MSP) and deploy the OpenIntuneBaseline to multiple customer tenants using CIPP.

The policy "Win - OIB - SC - Microsoft Office - U - Security" combines several Office security settings, including:

• File Block settings for legacy Office file formats
• Disabling "Allow Trusted Locations on the network (User)"
• Other general Microsoft Office security settings

This combination makes it difficult for us to deploy the policy unchanged.

All our customers use email archives, such as MailStore, as well as document management systems (DMS). These archives contain Office documents created over the past 10–15 years, including documents in legacy Office file formats. When we deploy the original OIB policy, users can no longer open some of these archived documents.

Consequently, we must remove the File Block settings from the policy for every customer deployment. This creates additional administrative effort and means that we cannot use the original OIB policy without modification.

The issue is compounded by the fact that our customers exclusively use Microsoft 365 Business Premium licensing. Compared with Microsoft 365 E3/E5, the available controls for legacy Office file formats are more limited. Where higher-tier licensing may allow legacy files to be opened in a restricted or read-only mode, our practical options with Business Premium are generally limited to allowing the files with full editing capabilities or blocking them entirely.

We encounter a similar, although less urgent, issue with “Allow Trusted Locations on the network (User)”. Some customers use complex Excel workbooks containing linked files, nested references, and dependencies stored on SMB shares. In these environments, properly configured network Trusted Locations may be required for the workflows to function correctly.

Describe the solution you'd like

I would like the policy "Win - OIB - SC - Microsoft Office - U - Security" to be split into two or preferably three more granular policies:

1. A general Microsoft Office user security policy containing the settings that are broadly applicable
2. A dedicated policy containing the File Block settings for legacy Office formats
3. Optionally, a dedicated policy containing the Trusted Locations settings, particularly "Allow Trusted Locations on the network (User)"

This would allow MSPs and other administrators to deploy the general Office security baseline unchanged while deciding separately whether File Block and Trusted Locations settings are appropriate for each environment.

It would also make exceptions more transparent and easier to maintain, as administrators could omit or replace a complete, clearly scoped policy instead of modifying individual settings within a broader policy.

Describe alternatives you’ve considered

Our current approach is to modify the imported policy for every customer and remove the File Block settings. Where necessary, we also adjust the Trusted Locations setting.

Another option would be to maintain our own customized version of the complete Office security policy. However, this increases the effort required to track upstream OIB changes and creates a risk that future security improvements will not be adopted consistently.

We could also create per-customer exclusions or replacement policies, but this adds complexity and makes deployments more difficult to standardize across multiple tenants.

Additional context

Full disclosure: We deploy the OIB through CIPP, so it is in our operational interest to use as many original OIB policies as possible without modification. Greater policy granularity would therefore make our multi-tenant administration considerably easier.

Nevertheless, I believe this separation could also benefit other organizations. File Block settings and network Trusted Locations are highly dependent on licensing, legacy document requirements, storage architecture, and established business workflows. Separating these settings from the general Office security policy would make it easier to adopt the remaining baseline without weakening or manually altering unrelated security controls.

LLM Disclaimer

I'm no native speaker. I wrote the entire text myself, and then asked a LLM to proofread it for me.

[Michael-eit]

I personally would rather the Baseline that should be modified by you for your tenants remin as a baseline.
Why not set up your own git and import the main one so you can just bind eye slap it on tenants (no one should ever do this) and create your customised ones there yourself. you can then still use CIPP to deply. The overhead as you say should not be pushed upstream beacuse you dont want to deal with it.
Your a MSP you should be doing the work anyway?

[xenadmin]

Thank you for sharing your perspective. I agree that a security baseline should never be applied blindly and that an MSP is responsible for assessing and adapting it to each customer’s technical and business requirements. That is exactly why we identified these settings as problematic rather than deploying the baseline without review.

However, I do not believe that this contradicts the proposed change. I am not requesting that any setting, security recommendation, or default value be removed or weakened. The request is exclusively for an administrative reorganization of the existing settings into more granular policies.

The current Microsoft Office user security policy is one of the largest policies in the baseline and combines controls that address substantially different use cases. Other areas of the OIB, such as the Microsoft Edge configuration, are already divided into considerably more granular policies. Applying a similar structure here would therefore not be inconsistent with the existing design of the project.

File Block settings in particular are highly dependent on licensing, legacy document requirements, and archive environments. Separating them from the general Office security settings would preserve the baseline recommendations while allowing administrators to make an explicit decision about this specific control. The same principle applies, although less critically, to network Trusted Locations.

Maintaining our own Git repository or fork is technically possible, but it introduces a separate configuration baseline that must continuously be compared with and updated against upstream changes. In practice, reliably following upstream changes is more complex than it may initially appear, especially when policies are imported and maintained across multiple tenants. Avoiding unnecessary divergence from upstream is sound configuration management, not an attempt to avoid the responsibilities of an MSP.

We already accept that customer-specific requirements must be evaluated and implemented by us. The purpose of this request is to make that customization more targeted and maintainable while retaining as much of the upstream baseline as possible without modification.

Ultimately, this is of course for the maintainers to evaluate against the project’s design principles and maintenance effort. Nevertheless, I believe the proposed split would improve modularity and reusability without changing the baseline’s security position, and that it could benefit organizations beyond our particular CIPP-based deployment model.

LLM Disclaimer: I'm no native speaker. I wrote the entire text myself, and then asked a LLM to proofread it for me.