How do you transition to modern device management in practice?

Remote work and increased workforce mobility have introduced new challenges for the operation of organizations’ IT systems and the management of workstations. Management must function regardless of where a workstation is located. With modern device management, all actions targeted at a workstation can be handled without a connection to the organization’s internal network. As a result, workstations remain continuously up to date while saving resources, and employees can stay productive.

Now we will take a closer look at how to transition to modern device management in practice. This blog was originally published in 2020 and updated in April 2026.

As a temporary workaround that gives you extra time to implement a long-term solution, you can postpone the activation of the new CSP using the script below. This immediately restores functionality to customizations broken by the security policy. However, activation can only be postponed until June 1, 2026. After that date (or preferably well before it), you must have a long-term solution in place.

See the script in the PDF file.

The second-fastest way to restore original functionality requires two relatively small changes. Both, however, involve potential security risks that you must understand and formally accept if you choose this path.

Adding external script domains to the Trusted Script Sources list

If a SharePoint customization depends on a script hosted on an external domain, you can make that script work again by adding the domain to the Trusted Script Sources list. Adding a third-party domain to this list introduces the following security risk:

The referenced JavaScript file hosted on a third-party domain may change in the future and begin to contain a vulnerability or even malicious code. This can happen, for example, if the third party is compromised. When the referenced JavaScript file is modified to include a vulnerability or an attack, the malicious code is loaded and executed in your SharePoint environment as soon as a user opens a page that references the file.

By adding a third-party domain to the Trusted Script Sources list, you are effectively placing full trust in that domain owner’s security practices and release processes. If their systems are breached, your SharePoint environment is next in line. For this reason, you should only add script sources to the Trusted Script Sources list when you fully control the content of those scripts and their update process.

If your customization currently relies on a script hosted on a third-party domain, it is recommended that you at least take a copy of the script (and verify that it contains no security vulnerabilities), host it either on the Microsoft 365 CDN or on your own externally managed CDN (for example, in Azure), and update the script reference to point to the version stored on that CDN. This way, only users in your organization who have access to the CDN can update the script.

If you choose to store a security-reviewed version of the script on an external CDN, you can add your CDN domain to the Trusted Script Sources list as follows:

1. Go to the SharePoint Online Admin Center

2. Open Advanced and select Script sources

3. Add your external CDN domain as a new trusted script source

Using the latest version of the React Script Editor web part

If you have used the open-source Script Editor web part to add customizations to SharePoint Online pages, you may have noticed that those customizations are now broken as well. At least for the time being, inline scripts can be made to work again by installing the latest version of the React Script Editor web part.

The latest version includes a change that bypasses SharePoint’s CSP restrictions by using the Function constructor. This works because SharePoint’s current CSP configuration includes the unsafe-eval directive, which allows the use of eval() and the Function() constructor.

However, this is not something you should build a long-term customization strategy on. If Microsoft decides in the future to remove the unsafe-eval directive from SharePoint’s CSP headers (which would be a perfectly reasonable security-hardening measure), this workaround will stop working immediately. You can read more about CSP headers and directives in MDN’s official documentation.

In addition to the business continuity risk mentioned above, using the Script Editor web part also involves the following security risk:

Anyone with permissions to edit a SharePoint page can attach arbitrary JavaScript code to it. This does not require a compromised account. A well-meaning content author might embed a seemingly useful snippet of code found online without understanding its security implications, inadvertently exposing users to a vulnerability.

And not all threat actors are external. While we generally want to trust our colleagues completely, organizations are made up of people who face complex situations and emotions. Organizational changes or layoffs, for example, can lead to frustration and questionable decisions. A malicious insider with page editing rights and access to the Script Editor web part can cause significant damage. You can read more about insider threats in the blog post Insider Risks and Threats – the Blind Spot of Cybersecurity?

A secure, modern, and Microsoft-recommended approach is to implement customizations as SharePoint Framework (SPFx) solutions.

Instead of injecting scripts into modern SharePoint pages, you create a properly packaged SPFx web part or extension. The code is reviewed, versioned, packaged, and then deployed to the tenant via the SharePoint App Catalog. This aligns with modern software development best practices and works naturally within the boundaries defined by SharePoint’s new Content Security Policy.

If the previous implementation relied on external JavaScript libraries, it is still possible to reference those scripts in SPFx solutions after first moving them to the Microsoft 365 CDN or the organization’s own CDN. However, it is recommended to reassess whether those dependencies are still necessary or whether the functionality can be implemented directly within the SPFx solution using modern libraries.

Moving from external script references and content-author–added inline scripts to proper SPFx solutions brings several benefits:

• Clearly organized source code that is easy to read

• Proper version control and code review processes, which are typically missing from ad hoc code snippets injected into pages

• A clear deployment and versioning model

• A more reliable way to manage applications and their associated permissions

• Alignment with Microsoft’s long-term roadmap

Yes, this requires more effort than simply adding a script to a page. But it also dramatically reduces security risks and the likelihood that your solution will break the next time Microsoft improves SharePoint’s security.