Adding a secret to an Azure Key Vault

An Azure Key Vault is a great location for storing credential securely. In a recent article I cover how to:

next, I want to cover how you can actually put credentials in there.

Step one is to navigate the Azure Key Vault you have created, and select the Secrets option from the menu on the left as shown above. From the menu on the right select +Generate/Import as shown.

Simply complete the fields as shown and select the Create button at the bottom of the window.

You will note that your secret (say a password) has a Name and potentially an activation and expiration date if desired. You can also enable or disable if desired.

You should now see that the secret has been created as shown above. To view the details simply click on the secret.

Here you’ll now see all the details about the secret. The good thing about information about an Azure Key Vault credential is that you can easily update it if required and previous versions will be retained. You can also control access to this individual secret via the Access control (IAM) on the menu on the left hand side.

If you now select the Current version displayed in the middle of the page you will get more details like so:

Here, you can update the settings for secret as well as reveal what the secret is by selecting the Show Secret Value button as shown.

You see the super secret password shown above.

One of the main reasons reasons for using an Azure Key Vault is that we can access this information also programmatically, for example by using PowerShell.

If I connect to Azure using the Azure PowerShell module with a user that has rights to access the vault and secret, I can run a command like:

get-azkeyvaultsecret -vaultname “vaultname” -name “secretname”

and the results will be shown above. But how do I get to the actual secret?

Basically, you repeat the previous command but this time assign it to a variable and add the –asplaintext option, like shown above. The command would look like:

$pwd = get-azkeyvaultsecret -vaultname “vaultname” -name “secretname” –asplaintext

Now the secret value (say password) is in the variable $pwd for use in my code.

PowerShell is not the only method you can use to obtain what is in an Azure Key Vault. You can use something like Power Automate and Flow, which I’ll cover off in an upcoming articles. However, PowerShell allows just about any function with vaults including creating, reading, deleting, updating and so on. Thus, using an Azure Key Vault provides a secure yet flexible method of storing credentials you want to protect as well as make potentially portable (i.e. you can use them anywhere on any device that runs PowerShell and connect to the internet).

So an Azure Key Vault provides secure storage for credentials that you can easily access programmatically using something like PowerShell and Power Automate. What can now be achieved with this? Stay tuned to find out more.

Create a new Azure Key Vault

Given that a number of upcoming articles will discuss Azure Key Vaults, I thought a good place to start was to show you how to set one up. It is pretty easy, so let’s do it!

You’ll need a paid Azure subscription and administrator access to your Azure portal.

In the Azure portal, search for Key Vaults as shown and select Key Vaults from the results.

Then select the option to Create a new vault as shown above.

Complete the details for the vault, including:

– Azure subscription

– Resource group

– Key vault name

– Region

– Pricing tier

most of the other options can be left at their defaults. Select the Next button at the bottom of the window to continue.

In this case the default Permissions model of Azure role-based access control is desired setting.

Generally, no further changes are required. Select Next at the bottom of the windows to continue.

Typically, no changes need to be made here as we will want this new vault to be available publicly via something like PowerShell. However, you can make whatever changes you desire and select the Next button at the bottom of the screen to continue.

Add tags if you wish and then select the Next button at the bottom of the window.

Review the settings you have made and select the Create button.

You should now see the new vault being provisioned as shown above.

When the provisioning you can select the option to view the result as shown above.

You can return to your new vault at any time by navigating to Key Vaults in the Azure portal where you should see the vault just created as shown above.

I’d also suggest you check some permissions before you leave. Open the newly created vault and select Secrets from the menu on the left. If you see the banner across the top as shown above the reads This operation is not allowed by RBAC then you’ll probably need to change some permissions.

Navigate to the Access Control (IAM) option from the menu on the left as shown above. Then on the right select +Add.

From the menu that appears select the Add role assignment as shown above.

Locate and select the Key Vault Administrator job function role as shown.

Select Next at the bottom of the screen to continue.

Click the +Select members hyperlink as shown above.

From the window that appears on the right, search for the user whom you want to have rights over the vault (typically the same user that is currently logged in). Press the Select button at the bottom of the window to continue.

The selected user(s) should now appear under the Members section as shown above.

Press the Next button to continue.

Select the Review + assign button at the bottom of the screen to complete the process.

If you now return to the Secrets area that displayed the original RBAC warning, after a minute or two, you should see that message is longer displayed. The user that you just added now has administrative rights to the vault.

If you want to learn more about what Azure Key Vaults are all about take a look at:

Azure Key Vault basic concepts

however, in essence they are going to place to store stuff you want kept secure, like configurations details, including passwords and then access them programmatically.

Monitoring a break glass account with Sentinel

In a previous article I covered off how to use Defender for Cloud Apps to monitor a break glass account. Typically, the alerts generated there will feed into Sentinel, however it is possible to configure Sentinel to perform a similar role.

The starting point is to use a KQL query like this:

SigninLogs
| where UserPrincipalName == “breakglass@domain.com”
| where OperationName == “Sign-in activity”
| project TimeGenerated, UserPrincipalName, ClientAppUsed, LocationDetails

If you run that query manually you’ll see a result like shown above. You will however also notice a New alert rule option in the top right of the window.

Selecting this will reveal two choices as shown above. Select Create Microsoft Sentinel alert to continue.

Make the appropriate settings in the General page, like shown above, and continue.

Here there are number of settings you can select but you will probably want to adjust how often the query is run as shown above. The important point to remember is that, as Azure is a consumption based billing model, there is a (very, very small charge) every time the query is run. Thus, the more often it runs the more it will cost.

When you have completed this section, move onto the Incident settings.

Here it is important to ensure that the option to Create incidents is Enabled as shown above.

Make any additional adjustments and move to Automated response.

Here you can enable any automation action you wish by selecting from those already created, as shown above. You can always add additional automation later if desired.

Finally, review and create the alert.

Verify that the alert you just created now appears in the list of Analytic rules for your environment as shown above.

If you now test this by logging as your breakglass account you should an incident generated as shown above. Once again, it is important to remember that this incident doesn’t appear immediately. It will appear in a time period based on how often you set the alert to check.

Another important thing to remember is that by default, the incident will not send an email notification of the alert. You can configure that a variety of different ways if you wish, which I won’t cover here.

The differences with using Sentinel for custom alerts is that the billing is consumption based, but you have a lot more flexibility in how you configure the actual alerts as well as any automated response if desired. I would also say that Sentinel has more power around actually analysing signals as well which is handy to protect your breakglass account.

Monitoring a break glass account with Defender for Cloud Apps

It is a very good thing to have a breakglass account in your environment. I have spoken about this in depth in an episode of my podcast:

Need to Know podcast – Episode 310

The challenge can be ensuring you know if and when this account is used because it typically has less protection associated with it than normal accounts in the environment.

One way to achieve this is to use Defender for Cloud Apps, which can be found by navigating to:

https://security.microsoft.com

to generate alerts when the account logs into the environment.

On the left hand menu of the Microsoft Security Center for your tenant expand the Policies option under the Cloud apps heading, and select the Policy management item.

Now select the +Create policy menu item on the right as shown above.

From the drop down that appears, select Activity policy as shown above.

Give the new policy a Name and Description. Select the Policy severity and the Category.

Select the option to Act on: Single activity.

In the Activities matching all of the following select:

Activity Type equals Log on

then add another filter and select:

User Name equals breakglassaccount@domain.com as Any role

as shown above. This in essence will trigger and alert whenever the breakglass account logs into the environment.

Configure the Alerts and Governance actions to suit your requirements. At a minimum you probably want the alert to be emailed to an external address. You can also build a Power Automate Flow from this also if you wish.

Save the new policy.

Locate the policy just created in the list (you can sort using the Modified column if necessary). Select the ellipse (three dots) to the right of the policy entry and from the menu that appears, select View all matches as shown above.

Ensure you test the policy by logging into your breakglass account.

This will now show all the matches in your environment as shown above. It is also recommended that you Save as so you can easily return these results if needed in the Activity log.

If you have also set up Sentinel, the alert should also flow into here as shown above. More automation and alert options are available here if needed.

The most important thing to remember that any alert generated by the login of your breakglass will NOT be immediate! It should however appear with a a few minutes of the action taking place and then a little while after in Sentinel as it flows through the logging process.

There is more that can be done to with this process, but this should get you started protecting your breakglass account.

Block applications on Windows devices using Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

5. Managing browser extensions in Edge with Intune

6. Setting an Edge Security Baseline with Intune

7. Setting an individual Attack Surface Reduction (ASR) rule in Intune

8. Setting Edge as the default browser using Intune

Now that we have Microsoft Edge all set up and have done as much as we can to encourage people to shift away from using other browsers, it’s now time block any other browsing options. We can again use Intune to achieve this and, typically, it can be done using a number of different methods. Here, we’ll use what I consider the easiest method.

Once again, create a Configuration profile for Windows 10 and later using the Settings catalog as shown above.

Give the policy a suitable name and continue.

In the search field type ‘specified windows application’ and select Search. The only category that appears should be Administrative Templates\System, which you should select. Then in the lower pane select Don’t run specified Windows applications (User) as shown above.

Enable the Don’t run specified Windows applications (User) and then enter the name of the applications you do not wish to run. Here, we’ll block chrome.exe and brave.exe as shown above.

These settings are covered in the RestrictApps documentation in which you will note:

1. The setting applies to users not devices:

and

2. This policy setting only prevents users from running programs that are started by the File Explorer process. It doesn’t prevent users from running programs such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting doesn’t prevent them from starting programs in the command window even though they would be prevented from doing so using File Explorer.

3. Blocking occurs by filename only. If users can rename the file then it will execute.

As mentioned previously, this is but the simplest method to block existing applications from running. Other options are available if you wish a more comprehensive blocking approach.

Finish configuring the policy remembering to assign it to a user NOT device group.

Once the policy has been deployed to your fleet and these machines have been rebooted, when a user tried to run an application that you have specified as block in the policy they will receive message like that shown above.

The good thing about this policy is that you can easily extend it to include any other applications you don’t users to run on their Windows devices.

Setting Edge as the default browser using Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

5. Managing browser extensions in Edge with Intune

6. Setting an Edge Security Baseline with Intune

7. Setting an individual Attack Surface Reduction (ASR) rule in Intune

Now that Microsoft Edge has been secured in the environment, the next task will be to set Microsoft Edge as the default browser. There are number of ways of achieving this, but I’ll use the more modern Intune Settings catalog approach.

The first step in the process is to take a machine that already has Microsoft Edge configured as the default browser app and run the command:

dism /online /export-defaultappassociations:edgedefault.xml

This will produce an XML with all the application defaults for that device.

If you just want to configure Microsoft Edge as the default browser you’ll need to edit the XML file until it looks something like this:

<?xml version=”1.0″ encoding=”UTF-8″?>
<DefaultAssociations>
     <Association Identifier=”.htm” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.html” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.mht” ProgId=”MSEdgeMHT” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.mhtml” ProgId=”MSEdgeMHT” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.pdf” ProgId=”MSEdgePDF” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.svg” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.xht” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.xhtml” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”ftp” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”http” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”https” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”microsoft-edge” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”microsoft-edge-holographic” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”ms-xbl-3d8b930f” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”read” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
</DefaultAssociations>

Next, you’ll need to convert that XML file to a base64 file for us an Intune policy. You can do that using the following site:

https://www.base64encode.org/

The output from this conversion should look like this:

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxEZWZhdWx0QXNzb2NpYXRpb25zPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSIuaHRtIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLmh0bWwiIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSIubWh0IiBQcm9nSWQ9Ik1TRWRnZU1IVCIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLm1odG1sIiBQcm9nSWQ9Ik1TRWRnZU1IVCIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLnBkZiIgUHJvZ0lkPSJNU0VkZ2VQREYiIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9Ii5zdmciIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSIueGh0IiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLnhodG1sIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iZnRwIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iaHR0cCIgUHJvZ0lkPSJNU0VkZ2VIVE0iIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9Imh0dHBzIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0ibWljcm9zb2Z0LWVkZ2UiIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSJtaWNyb3NvZnQtZWRnZS1ob2xvZ3JhcGhpYyIgUHJvZ0lkPSJNU0VkZ2VIVE0iIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9Im1zLXhibC0zZDhiOTMwZiIgUHJvZ0lkPSJNU0VkZ2VIVE0iIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9InJlYWQiIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KPC9EZWZhdWx0QXNzb2NpYXRpb25zPg==

In the Intune console, create a new Device Configuration profile using the Settings Catalog:

Give the new policy a meaningful name and continue.

In the Settings picker search for applications and then select Application defaults and then Default Associations Configuration in the results as shown above.

Into the option Default Associations Configuration paste a copy of the base64 file you created from the original XML.

Complete the policy by assigning it to a group of devices NOT users. This is because the Policy CSP – ApplicationDefaults is only scoped to devices per:

This may mean you need to create a different Edge configuration policy from the one created in previous steps, if that policy was assigned to users.

When the policy has been deployed from Intune, and the device rebooted, Microsoft Edge will be the default browser for the device.

Of course, the user can still change the default back but they will need to do that after every reboot. In the future, you’d create a policy to prevent that, but for now, if the user is that desperate for their old browser they can swap. However, the next policy I’ll cover will show you how to stop other browsers (or any other application) from running on Windows devices.

Setting an individual Attack Surface Reduction (ASR) rule in Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

5. Managing browser extensions in Edge with Intune

6. Setting an Edge Security Baseline with Intune

The next recommended setting to implement is Attack Surface Reduction (ASR) rules. I’ve detailed how you can set this on individual devices using PowerShell here:

Show ASR settings for device with PowerShell

I’ve also detailed how to do this with Intune previously:

Attack surface reduction for Windows 10

In a nutshell, ASR is going to prevent child processes from launching, which is typically how a malware infection starts.

To create a stand alone ASR rule navigate to Endpoint security, Attack surface reduction in the Intune portal and select Create policy, as shown above.

Select the platform as Windows 10, Windows 11 and Windows Server and the profile as Attack Surface Reduction Rules.

Then Create the policy

As always, give the policy a meaningful name.

You should then see a list of the 16 standard ASR rule types as well as a rule called Block Webshell creation for Severs.

The best practice is to set all of these to Block. However, you will also see options for Audit and Warn if you want to take a more cautious approach.

The good thing about an individual ASR policy like this is that you get a lot more options that can be configured, unlike other policies in Intune that also include ASR. An example if the above, where you can provide enter a directory or file which will prevent ASR rules from matching. As an example, a path might be defined as: C:\Windows to exclude all files in this directory. A fully qualified resource name might be defined as: C:\Windows\App.exe.

Best practice is not to have any exclusions.

A little further down you’ll see a setting for Enable Controlled Folder Access as shown above. The controlled folder access feature removes modify and delete permissions from untrusted applications to certain folders such as My Documents.

Best Practice is to set this to Enabled.

Under this you can set Controlled Folder Access Protected Folders and Controlled Folder Access Allowed Applications. Controlled Folder Access Protected Folder allows adding user-specified folder locations to the controlled folder access feature. These folders will complement the system defined folders such as My Documents and My Pictures. The Controlled Folder Access Allowed Applications allows user-specified applications to the controlled folder access feature. Adding an allowed application means the controlled folder access feature will allow the application to modify or delete content in certain folders such as My Documents. In most cases it will not be necessary to add entries. Windows Defender Antivirus will automatically detect and dynamically add applications that are friendly.

Best practice is to not have any settings here and to have these both set to Not configured.

When you configure an individual rule you’ll also see the ability to set exceptions for just this rule. As an example, a path might be defined as: c:\Windows to exclude all files in this directory. A fully qualified resource name might be defined as: C:\Windows\App.exe.

Once you have determined your settings you then apply the policy to an audience in your environment. You can use multiple policies if needed for different audiences.

If you want to monitor ASR actions in your environment you can use the following KQL query:

DeviceEvents
| where ActionType startswith ‘Asr’

This going to help you identify which devices and processes ASR is impacting, making troubleshooting much easier.

If you want to read more about ASR then visit:

Understand and use attack surface reduction capabilities

I believe ASR is something that should be enabled fully on all Windows devices, withou any exceptions or exclusions. It is an ability included with Windows for free and just needs to be enabled, either by policy or PowerShell. I would recommend setting an individual ASR policy as I have shown above as it provides the greatest flexibility when configuring as well as the greatest number of exclusions if required. Many other Intune policies include the ability to configure ASR but if you have a stand alone policy you should not configure it elsewhere or you may end up with configuration clashes and errors.

The next recommended policy will be for Defender for Endpoint.

Setting an Edge Security Baseline with Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

5. Managing browser extensions in Edge with Intune

The next step in the process is to assign a security baseline to the Microsoft Edge environment. Security baseline policies differ from all other policies in Intune because they already have best practice settings enabled. This compares to other Intune policies where you need to go into each policy item and set them to the desired setting. Another benefit of using Security baselines is that they are easily upgradable when updated policies become available. These two factors save a lot of time and effort securing your environment.

In the Intune console, navigate to Endpoint security | Security baselines and select Security Baseline for Microsoft Edge as shown.

Select the option to Create profile and then give the profile a meaningful name.

You’ll then see a list of the individual settings with values already selected.

You can adjust any of the individual settings if you need to customise the policy. Generally, I find there is no need to make any changes here as I have found no conflicts.

Here we also find an example of one of the challenging things with implementing any policy, duplicate settings. If you remember back to the previous article on

Managing browser extensions in Edge with Intune

you’ll note that extension restrictions was configured there, but now it is also in this Security baseline policy. A best practice recommendation is to only have one place in your policies where a setting is made. This will avoid conflicts and aid troubleshooting. If you do choose to retain the same settings in multiple policies, ensure they are set identically or otherwise you will get conflicts. In this case I’ll leave the setting in place for both policies as they are the same and it is bit challenging to disable just this option in the original ‘Edge configuration’ policy created in the previous post.

With any changes made, continue with the Security baseline policy configuration and assign it to your environment.

When complete you should see the policy you just created, as shown above. Remember, you can create as many policies as you need to accommodate your environment targeted to different audiences, however the aim should be to get to a single Security baseline policy for Edge to keep things simple.

You’ll see that the policy created has a version number. You’ll also note a Change version button on the menu at the top (currently greyed out) as shown above. This is the beauty of a Security baseline policy, when an update is available you’ll be able to use this option to update the policy. You can read more about this here:

Update a profile to the latest version

We are now at a point in our roll out where we have policies to provide a secure Microsoft Edge configuration in our environment. Those already using Microsoft Edge will benefit immediately, users on other browsers still need to ‘encouraged’ to make the shift as soon as possible, but are still not being forced to use Microsoft Edge just yet (they will be eventually, so keep encouraging them to make the shift with your communications because they day when they have no other option but to switch is coming!).

for more information about the:

Microsoft Edge security baseline settings reference for Microsoft Intune

visit the above link and remember the benefit of Security baselines is that they have best practice settings already enabled, so typically all that is needed to apply the policy with these default settings .

It is now time to look at securing the Windows devices against ransomware. Stay tuned.