I encountered the following scenario in a client’s environment recently:

When you remove a Virtual Machine (VM) from Azure Security Center’s (ASC) Just-In-Time (JIT) VM Access control, while it’s associated Network Security Group (NSG) is contained within a Resource Group that has a Resource Lock (more specifically the Delete Lock) enabled, the removal process is “successful” but does not remove the Network Security Group (NSG) rules, and also shows the VM as being both “configured” and “recommended” for the ASC JIT VM Access control.

Let’s dive into this scenario in more detail.

The Environment

I have a single Resource Group that contains my Virtual Machine. This VM does not have it’s own NIC-based Network Security Group (NSG), but there is an NSG on the Subnet it’s attached to.

The default, basic (uncustomized) Network Security Group (NSG) rules looks like the following:

Network Security Group (NSG) Default Configuration

For simplicity, I have the VM, along with the associated VNet and NSGs all contained within the same Resource Group. In a more real-world scenario, the VNet and it’s associated NSGs would be contained in a separate Resource Group to facilitate more granular Role-Based Access Control (RBAC). In reality, this bug is not an issue with the VM or it’s Resource Group being locked, but ultimately the VNet’s Resource Group (which, should also be locked anyways due to it containing Production-sensitive components).

Resource Group Resources

Initial Configuration

Once my VM is deployed, within approximately 10 minutes, it appears in Azure Security Center (ASC), within the Just-In-Time (JIT) access control’s “Recommended” list.

Azure Security Center (ASC) – Just-In-Time (JIT) VM Access – Recommended

After enabling JIT for the target VM, the Network Security Group (NSG) Inbound Security Rules look like the following. Notice the addition of the Security Center JIT rules.

Network Security Group (NSG) – Just-In-Time (JIT) – Inbound Security Rules

Now with JIT enabled, I have also applied a Resource Lock (specifically the Delete Lock) on the Resource Group (RG) that contains the VNet.

In reality, you could apply the Delete Resource Lock on the Resource Group at anytime after the VNet and NSG were originally created.

Resource Group – Delete Lock

The Issue/Bug

Now with all of that described and setup, let’s see the scenario described at the outset of this article in action.

Going back into the Azure Security Center (ASC)’s Just-In-Time (JIT) VM Access control blade, and selecting our target VM, we can now opt to remove the VM from the JIT VM access control.

Azure Security Center (ASC) – Just-In-Time (JIT) VM Access – Remove VM

When you do that, the VM will instantly be removed from the “Configured” list. However, there are absolutely no Azure Notifications that appear (as does with most other Azure portal actions).

Azure Notifications Pane

But, if we go and look at the Azure Activity Logs (as is suggested), we can clearly see a failed attempt for the “Delete JIT Network Access Policies” operation.

And, looking into the actual Activity Log details, we see, of course, this is because the Resource Group that contains the Network Security Group (NSG) has a Delete Resource Lock on it.

Azure Activity Log – Failed JIT Rule Removal

But, from within Azure Security Center (ASC), it clearly showed the VM as removed, and the VM re-appears in the “Recommended” list.


Through additional testing, in my case, the VM actually is re-added to the “Configured” list within a few minutes, and the “Recommended list shows a resolved high severity recommendation.

Azure Security Center (ASC) – Just-In-Time (JIT) VM Access – Recommended

However, in my originally testing, because the VM was actually shown as removed from JIT control (and showed up in the “Recommended” list), but the NSG rules remained, I went and removed the Delete Lock from the Resource Group, and manually deleted the JIT Rules!

Azure Security Center (ASC) – JIT Rules – Manual Deletion

This then puts my Network Security Group (NSG), and Azure Security Center (ASC)’s configuration out of alignment. Because ASC things the NSG still has the JIT rules, even though it does not.

This is a more of a serious issue, as it gives a false sense of protection. After all, Azure Security Center (ASC) says the VM is protected. But in reality it is not.


I call this a workaround, because really, Azure Security Center (ASC) should include some Azure Notifications details, along with immediately blocking the attempt at removing a VM from JIT control when the associated NSG is locked; let alone giving the impression that the VM is actually removed from JIT, only to re-appear several minutes later.

If you were attempting to complete this via automation, either through a PowerShell script, CLI, or possibly an ARM template, I’m curious if you would receive a false-positive “success” message. That could cause an issue with expected environment configuration versus actual configuration.

Note: I have not attempted this through any automation method, just from within the Azure portal. If you’ve attempted such, and can provide some real-world details, please reach out and share those details, and I will update this blog post accordingly.

The workaround I’ve found to work is to remove the VM from the Just-In-Time (JIT) VM Access control, and wait for it to reappear in the “Recommended” list, in order to put the JIT Rules back into the NSG. In my case, it took approximately 15 minutes or so for the VM to reappear in the list.

While this does work, it leaves something to be desired, since you will be potentially exposing your VM to brute-force attacks (albeit for a small timeframe).


Hopefully this article is of some help if you find yourself (or your clients) in a similar scenario.

Also, by way of full transparency, when I originally discovered this scenario/bug, I contacted the Azure Security Center (ASC) Product Group (PG) directly to inform them about it. I am now working with the engineering team to correct this scenario.