Automate Network Access with Logic Apps

Build a Logic App that automatically blocks internet traffic on an NSG.

Introduction

30 Second Summary

Imagine your company needs to cut off internet access to a private network every quarter for a compliance audit. Doing this manually means someone has to remember the exact date, log in, and update firewall rules by hand.

In this project, you will build an Azure Logic App that automatically blocks internet traffic on a Network Security Group when a cutoff date passes. It authenticates to the Azure REST API using a managed identity, so no credentials are stored anywhere.

What You'll Build

A Consumption Logic App that runs on a daily schedule, checks whether today's date has passed a configurable cutoff, and calls the Azure REST API to add a Deny rule to a Network Security Group protecting your subnet.

By the end of this project, you'll have:

A Virtual Network and Network Security Group protecting a subnet from unwanted internet traffic.
A Consumption Logic App with a system-assigned managed identity that authenticates to the Azure REST API without storing credentials.
A complete workflow with a Recurrence trigger, Condition action, and HTTP action that enforces network access control on a daily schedule.
A secret mission extension that sends email notifications whenever your Logic App blocks internet traffic.

Are there any prerequisites?

You need an Azure subscription with permissions to create resources and assign roles. A modern web browser is all you need on your machine. The entire project is done in the Azure portal, so no local tooling or code editors are required.

Create Your Azure Networking Resources

Every network security automation needs infrastructure to protect. In this project, your Logic App will control a Network Security Group that guards a Virtual Network and subnet in Azure.

Before you build the automation, you need that networking foundation in place. In this step, you'll create the Virtual Network, subnet, and Network Security Group that the Logic App will manage.

In this step, get ready to:

Create a resource group, Virtual Network, and subnet in the Azure portal.
Create a Network Security Group with default security rules.
Associate the NSG with your subnet so it controls inbound traffic.

Create a resource group, Virtual Network, and subnet

A resource group is a container that holds related Azure resources together. You'll create one first so everything is organized and easy to clean up when you're done.

Open the Azure portal at portal.azure.com in your browser.
In the search bar at the top, type Resource groups.
Select Resource groups from the results.
Select Create.
For Resource group, enter nsg-logicapp-rg.
For Region, select East US.
Select Review + create, then select Create.

Pro tip: keep the same region

You can use a different region if East US isn't close to you. Just make sure you use the same region for every resource in this project.

You should see a notification saying the resource group was created successfully.

Now you'll create the Virtual Network that your NSG will protect. A Virtual Network is Azure's version of a private network, and a subnet is a segment within it where resources live.

In the search bar at the top, type Virtual networks.
Select Virtual networks from the results.
Select Create.
For Resource group, select nsg-logicapp-rg.
For Virtual network name, enter demo-vnet.
For Region, select the same region you used for your resource group.
Select the IP Addresses tab at the top.

On the IP Addresses tab, you'll see a default address space of 10.0.0.0/16 and a default subnet with range 10.0.0.0/24. Keep both of these defaults.

Select the default subnet row to open its settings.
Change the Name field from default to app-subnet.
Select Save to close the subnet settings.
Select Review + create, then select Create.

Wait for the deployment to complete. You should see a Your deployment is complete message.

What is a Virtual Network?

A Virtual Network (VNet) is an isolated private network inside Azure. Resources inside a VNet can talk to each other, but traffic from the outside internet is blocked by default.

A subnet divides the VNet into smaller segments. Your app-subnet is where applications would live in a real environment. The NSG you create next will act as a firewall for this subnet.

Deployment failed?

Make sure you selected nsg-logicapp-rg as the resource group, not a different one. Also confirm the region matches the resource group's region.

If you see a naming conflict, another VNet with the name demo-vnet may already exist. Delete it first or choose a different name.

Help me troubleshoot my Virtual Network deployment error.

Create a Network Security Group

A Network Security Group (NSG) is a set of firewall rules that control which traffic can flow in and out of a subnet. Your Logic App will add a rule to this NSG to block internet traffic.

In the search bar at the top of the Azure portal, type Network security groups.
Select Network security groups from the results.
Select Create.
For Resource group, select nsg-logicapp-rg.
For Name, enter demo-nsg.
For Region, select the same region as your other resources.
Select Review + create, then select Create.

Wait for the deployment to complete, then select Go to resource.

On the demo-nsg overview page, select Inbound security rules under Settings in the left sidebar.

You should see three default rules listed: AllowVnetInBound, AllowAzureLoadBalancerInBound, and DenyAllInBound.

What are the default NSG rules?

Azure creates these three inbound rules on every NSG automatically. You cannot delete them, but you can override them by creating custom rules with higher priority (lower priority numbers).

AllowVnetInBound allows resources inside the VNet to talk to each other.
AllowAzureLoadBalancerInBound allows Azure's load balancer health probes to reach your resources.
DenyAllInBound blocks all other inbound traffic by default. Your Logic App will add a higher-priority custom deny rule later to explicitly block internet sources.

Associate the NSG with your subnet

An NSG on its own doesn't protect anything. You need to associate it with a subnet for its rules to take effect on traffic flowing in and out of that subnet.

Inside the demo-nsg resource, select Subnets under Settings in the left sidebar.
Select Associate at the top.
For Virtual network, select demo-vnet.
For Subnet, select app-subnet.
Select OK.

After a moment, app-subnet appears in the Subnets list. This confirms that demo-nsg is now controlling traffic for that subnet.

Don't see demo-vnet in the dropdown?

The Virtual Network and NSG must be in the same Azure region. If demo-vnet doesn't appear, go back to the demo-nsg overview page and check its region against the region you used for demo-vnet.

If they're different, delete the mismatched resource and recreate it in the correct region.

Help me fix my NSG subnet association issue.

Why associate instead of just creating rules?

An NSG is just a container for security rules. Until you associate it with a subnet (or a network interface), those rules have no effect. Think of it like writing traffic laws that only apply to a specific highway. The association tells Azure which highway the laws apply to.

Your networking foundation is ready. You have a Virtual Network, a subnet, and an NSG guarding it. Next up, you'll create the Logic App that will automatically add deny rules to this NSG.

Create the Logic App and Enable Managed Identity

Your networking infrastructure is set up. You have a Virtual Network, a subnet, and a Network Security Group ready to protect it.

Now you need the automation engine that manages those network rules. In this step, you'll create a Logic App and give it a managed identity so it can authenticate to Azure's REST API without stored credentials.

In this step, get ready to:

Create a Consumption Logic App in your resource group.
Enable a system-assigned managed identity so the Logic App can authenticate to Azure APIs.

Create a Consumption Logic App

In the Azure portal, type Logic apps in the search bar at the top of the page.
Select Logic apps from the search results.
Select Add at the top of the Logic apps page.
Select Consumption (Multi-tenant) as the plan type.
Click Select to continue to the creation form.
Select your Azure subscription in the Subscription dropdown.
Select nsg-logicapp-rg for the Resource Group field.
Enter nsg-access-controller in the Logic App name field.
Select the same region you used for your other resources in the Region dropdown.
Select No for Enable log analytics.
Select Review + create.
Select Create.
After deployment completes, select Go to resource.

You should see the Logic App's Overview page with the name nsg-access-controller displayed at the top.

What is a Consumption Logic App?

A Consumption Logic App is a cloud workflow that runs on a pay-per-execution model. You only pay when the workflow actually runs, and each execution costs fractions of a cent. There is no server or hosting plan to manage.

Why Consumption instead of Standard?

Azure offers two Logic App plan types. Standard Logic Apps require an App Service Plan, which adds hosting infrastructure you would need to configure and pay for. Consumption Logic Apps skip all of that. For a project where you run a handful of test executions, Consumption keeps the cost at essentially zero and the setup simple.

Logic App not creating?

Double-check that the Region you selected matches the region of your nsg-logicapp-rg resource group.
If you see a validation error about the name, try a slightly different name like nsg-access-controller-01. The name may already be in use in your subscription.
Make sure you selected Consumption (Multi-tenant) and not Standard. The creation form looks different for each plan type.

Why is my Logic App creation failing in the Azure portal?

Enable the system-assigned managed identity

Your Logic App needs a way to prove who it is when it calls Azure's management APIs. A managed identity gives the Logic App its own identity in Azure, so it can authenticate without you storing any passwords or API keys.

In your Logic App resource, expand the Settings section in the left sidebar.
Select Identity.
Under the System assigned tab, switch the Status toggle to On.
Select Save.
A confirmation prompt appears asking if you want to enable the system-assigned managed identity. Select Yes.

After a moment, an Object ID appears on the page. This is your Logic App's unique identity in Microsoft Entra ID.

Copy the Object ID value by clicking the copy icon next to it.
Save this value somewhere accessible, like a text file or sticky note. You need it in the next step.

What is a managed identity?

A managed identity is an automatically managed credential that Azure creates for your resource. Instead of storing a username and password or an API key in your Logic App, Azure handles the authentication behind the scenes. Your Logic App presents its identity to other Azure services, and Azure verifies it.

The Object ID you just copied is the unique identifier for this identity. You will use it in the next step to grant the Logic App specific permissions.

Don't see the Object ID?

Make sure you selected Save after switching the status to On. Flipping the toggle alone does not enable the identity.
If you accidentally dismissed the confirmation prompt, switch the toggle off and back on, then select Save again.
Try refreshing the page if the Object ID does not appear after a few seconds.

Why isn't my managed identity Object ID showing up?

Your Logic App is created and has its own identity in Azure. Next, you'll grant it permission to modify the Network Security Group so it can actually create deny rules.

Grant the Logic App Permission to Modify the NSG

Your Logic App now has a managed identity in Microsoft Entra ID. However, having an identity does not automatically grant any permissions.

Before the Logic App can create or update NSG rules, you need to explicitly grant it access using Azure RBAC. You'll assign the Network Contributor role, which is the narrowest built-in role that allows writing security rules.

In this step, get ready to:

Navigate to the NSG's access control settings.
Assign the Network Contributor role to the Logic App's managed identity.

Navigate to the NSG's access control page

Role assignments are configured on the target resource, not on the identity itself. Since the Logic App needs to modify the NSG, you'll assign the role from the NSG's perspective.

In the Azure portal search bar at the top, type Network security groups and select it from the results.
Select demo-nsg to open it.
In the left sidebar, select Access control (IAM).
Select Add, then select Add role assignment.

The role assignment wizard opens with a list of available roles.

Assign the Network Contributor role

The Network Contributor role grants permission to manage network resources, including creating and updating NSG security rules. This is more targeted than a broad Contributor role.

On the Role tab, type Network Contributor in the search box.
Select Network Contributor from the results.
Select Next.
On the Members tab, find the Assign access to section and select Managed identity.
Select + Select members.
In the Select managed identities pane that appears on the right, set the Managed identity dropdown to Logic app.
Find and select nsg-access-controller from the list.
Select Select at the bottom of the pane.
Select Review + assign.
Select Review + assign again to confirm.

After a few seconds, the role assignment is created. You should see a notification confirming the assignment was added.

To verify, select the Role assignments tab on the Access control (IAM) page.
You should see nsg-access-controller listed with the Network Contributor role.

Why Network Contributor instead of Contributor?

The Contributor role would also work, but it grants far more permissions than needed. Network Contributor is the narrowest built-in role that includes the Microsoft.Network/networkSecurityGroups/securityRules/write permission your Logic App requires.

This follows the principle of least privilege. Only grant the minimum permissions a resource needs to do its job.

Don't see your Logic App in the member list?

Make sure the Managed identity dropdown is set to Logic app and not another resource type. Also confirm the subscription filter at the top of the pane matches the subscription where you created the Logic App.

If the Logic App still does not appear, go back to the Logic App's Identity page and confirm the system-assigned identity shows Status: On with a valid Object ID.

help me troubleshoot why my Logic App doesn't appear in the managed identity member list

Your Logic App now has the exact permissions it needs to create security rules on your NSG. Next up, you'll build the actual workflow that checks the date and calls the Azure REST API to add the Deny rule.

Build the Logic App Workflow

Your Logic App now has its own identity and the permissions to modify your NSG. The foundation is set. Time to build the workflow that puts those permissions to use.

You'll wire together three components: a daily schedule trigger, a date-checking condition, and an HTTP call to the Azure REST API that adds a Deny rule to your Network Security Group.

In this step, get ready to:

Add a Recurrence trigger to run the workflow on a daily schedule.
Add a Condition that checks whether today's date has passed a cutoff date.
Add an HTTP action that calls the Azure REST API to create a Deny rule on the NSG.

Add the Recurrence trigger

Every Logic App workflow starts with a trigger that defines when it runs. The Recurrence trigger lets you set a repeating schedule without any external event.

Navigate back to your Logic App resource (nsg-access-controller).
In the sidebar, go to Development Tools, then select Logic app designer.
In the designer, select Add a trigger.
Search for Schedule and select the Recurrence trigger.
Set Interval to 1.
Set Frequency to Day.
Select Add new parameter.
Check the boxes for Time Zone, At These Hours, and At These Minutes.
Set Time Zone to your local time zone.
Set At These Hours to 8.
Set At These Minutes to 0.

What does this trigger do?

This Recurrence trigger fires once per day at 8:00 AM in your time zone. Each time it fires, the Logic App wakes up and runs the rest of the workflow you'll build next.

Add a Condition to check the cutoff date

The workflow should only apply the Deny rule after a specific cutoff date. A Condition action lets you branch the workflow into a True path and a False path based on an expression you define.

Below the Recurrence trigger, select the + icon.
Select Add an action.
Search for Control and select the Condition action.

Now configure the condition's three parts: the left value, the operator, and the right value.

Click inside the left Choose a value box.
Select the Expression tab (the fx icon).
Type utcNow('yyyy-MM-dd') in the expression field.
Select OK to confirm the expression.
In the middle dropdown, select is greater than or equal to.
In the right Choose a value box, type 2026-04-25.

Why does string comparison work for dates?

The utcNow('yyyy-MM-dd') expression returns today's date as a string like 2026-04-28. The yyyy-MM-dd format is designed so that alphabetical order matches chronological order.

This means a simple "greater than or equal to" comparison works correctly without needing to parse actual date objects.

Why does the condition evaluate to True right now?

The sample cutoff date is 2026-04-25, and today is already past that date. When you test the workflow, the condition evaluates to True so you can see the full Deny rule get applied.

If you want to test the False path later, change the right value to a future date.

Expression not saving?

Make sure you selected the Expression tab (fx icon) before typing the expression. If you type it on the Dynamic content tab instead, the expression is treated as plain text and the condition won't work.

Also confirm you selected OK after typing the expression. The left value box should show the expression text, not be empty.

Help me fix my Condition expression in the Logic App designer.

Add the HTTP action to create the Deny rule

When the condition evaluates to True, the workflow needs to call the Azure REST API to create a security rule on your NSG. The HTTP action makes this API call directly, using the managed identity you set up earlier for authentication.

Inside the True branch of the Condition, select Add an action.
Search for HTTP and select the built-in HTTP action.
Set Method to PUT.

The URI tells Azure exactly which NSG rule to create. You need your Azure subscription ID to build it.

Find your subscription ID by searching for Subscriptions in the Azure portal search bar and copying the Subscription ID value.
Paste the following URI into the URI field, replacing the placeholder with your actual subscription ID:

https://management.azure.com/subscriptions/[[SUBSCRIPTION_ID="your Azure subscription ID"]]/resourceGroups/nsg-logicapp-rg/providers/Microsoft.Network/networkSecurityGroups/demo-nsg/securityRules/DenyAllInternetInbound?api-version=2024-05-01

What does this URI mean?

management.azure.com is the Azure Resource Manager API endpoint.
The path drills into your subscription, resource group, and the specific NSG (demo-nsg).
DenyAllInternetInbound is the name of the security rule being created.
api-version=2024-05-01 specifies which version of the REST API to use.

Next, add the request header and body that define the Deny rule.

Select Advanced parameters.
Check the boxes for Headers and Body.
In the Headers section, enter Content-Type as the key.
Enter application/json as the value.
Paste the following JSON into the Body field:

{
  "properties": {
    "access": "Deny",
    "direction": "Inbound",
    "priority": 100,
    "protocol": "*",
    "sourceAddressPrefix": "Internet",
    "sourcePortRange": "*",
    "destinationAddressPrefix": "*",
    "destinationPortRange": "*",
    "description": "Block all inbound internet traffic - applied by Logic App"
  }
}

What does this JSON body do?

This is the payload that tells Azure how to configure the new security rule on your NSG.

access: Deny blocks traffic instead of allowing it.
direction: Inbound targets traffic coming into the subnet.
priority: 100 gives this rule the highest possible custom priority, so it takes effect before any lower-priority Allow rules.
sourceAddressPrefix: Internet is a service tag that matches all traffic originating from the public internet.
The wildcard * values for protocol and port ranges mean the rule applies to every protocol and every port.

Why use the HTTP action instead of a built-in connector?

Azure Logic Apps offers an Azure Resource Manager connector that can manage resources for you. The HTTP action calling the REST API directly is more transparent.

You see exactly what API endpoint is called, what the request body looks like, and how authentication works. This pattern transfers to any API, not just Azure's.

The last piece is authentication. You need to tell the HTTP action to use your Logic App's managed identity when calling the API.

Open the Advanced parameters list again.
Check Authentication.
Set Authentication type to Managed identity.
Set Managed identity to System-assigned managed identity.
Set Audience to https://management.azure.com/.
Select Save on the designer toolbar.

What is the Audience field?

The audience tells Azure which API the identity token is for. For any call to the Azure Resource Manager API, the audience must be https://management.azure.com/ (including the trailing slash).

Your designer should now show three connected blocks: Recurrence at the top, Condition in the middle, and HTTP inside the True branch.

Save failing or seeing an error?

Double check that your URI contains your actual subscription ID, not the placeholder text. You can verify your subscription ID by searching for Subscriptions in the Azure portal.

Make sure the Body field contains valid JSON with no trailing commas or missing quotes. Also confirm the Audience field is exactly https://management.azure.com/ with the trailing slash.

Help me troubleshoot my Logic App HTTP action configuration.

Your workflow is fully built and saved. Next up, you'll trigger a manual run and confirm that the Deny rule actually appears on your NSG.

Test and Verify Your Workflow

Your Logic App workflow is fully built with a daily schedule, a date-based condition, and an HTTP action that calls the Azure REST API. All the pieces are in place.

In this step, you'll trigger the workflow manually and confirm that it actually creates a Deny rule on your Network Security Group. This is the payoff for all the setup work in the previous steps.

In this step, get ready to:

Trigger the Logic App workflow manually.
Inspect the run history to confirm all actions succeeded.
Verify the Deny rule appears on the NSG.

Trigger a manual run

Your workflow is scheduled to run daily at 8:00 AM, but you don't need to wait. The Logic App designer lets you trigger a run on demand so you can test immediately.

Navigate back to your nsg-access-controller Logic App resource in the Azure portal.
On the sidebar, select Development Tools, then Logic app designer.
On the designer toolbar, select Run Trigger.
Select Run.

The workflow starts executing. Wait a few seconds for it to complete before moving on.

Why does the condition evaluate to True?

The cutoff date you configured is 2026-04-25. As long as you're running this project on or after April 25, 2026, the condition evaluates to True.

This causes the True branch to execute, which triggers the HTTP action to create the Deny rule on your NSG.

Check the run history

The run history shows you exactly what happened during execution. Each action in the workflow gets its own status, so you can pinpoint where things succeeded or failed.

On the sidebar of your Logic App resource, select Overview.
Under Run history, select the most recent run.

You should see all three steps with green checkmarks.

Recurrence shows Succeeded.
Condition shows Succeeded with a True result.
HTTP shows Succeeded with a 200 or 201 status code.

What do these status codes mean?

A 201 Created response means the Deny rule was created for the first time. A 200 OK response means the rule already existed and was updated. Either one means your workflow succeeded.

HTTP action showing an error?

Select the failed HTTP action in the run history to view the error details. Here are the most common causes:

Incorrect subscription ID in the URI. Double check that the subscription ID in the HTTP action's URI matches your actual Azure subscription ID. You can find it by searching for Subscriptions in the Azure portal.
Missing role assignment. Confirm that the Network Contributor role is assigned to the Logic App's managed identity on the demo-nsg resource. Role assignments can take a few minutes to propagate.
Incorrect audience URL. The audience in the HTTP action's authentication settings must be https://management.azure.com/ with a trailing slash.

Help me debug my Logic App HTTP action error

Verify the Deny rule on the NSG

The run history confirms the workflow executed successfully. Now check the NSG itself to see the rule your Logic App created.

In the Azure portal search bar, type Network security groups and select it.
Select demo-nsg.
On the sidebar, select Settings, then Inbound security rules.

You should see a new rule named DenyAllInternetInbound at the top of the list. Confirm it has the following values:

Priority: 100
Source: Internet
Protocol: Any
Action: Deny

This rule now blocks all new inbound connections from the internet to any resource in the app-subnet. Your Logic App created this rule entirely on its own through the Azure REST API.

Does this rule kill active connections?

No. NSG rules are stateful, meaning they only affect new connections. If a resource in app-subnet already had an active inbound session, that session would continue uninterrupted.

The Deny rule prevents any new inbound internet traffic from being established. This is important to understand in production scenarios where you need to block future access without disrupting current users.

Don't see the DenyAllInternetInbound rule?

Go back to your Logic App's run history and confirm the HTTP action shows a 200 or 201 status code. If it failed, fix the issue using the troubleshooting guidance above and run the workflow again.
Make sure you're looking at Inbound security rules, not Outbound security rules. The rule is an inbound rule.
Try refreshing the page. The Azure portal sometimes takes a moment to display newly created rules.

Help me figure out why my NSG rule is missing after running the Logic App

Secret mission

Add an Email Notification When the Deny Rule Is Applied

Your Logic App blocks internet traffic automatically, but nobody knows it happened. In this secret mission, you'll add an email notification so you have an audit trail every time the deny rule is applied. This is a common pattern in production environments where security teams need visibility into automated changes.

Before you go

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The Virtual Network and NSG are free Azure resources. The Consumption Logic App costs fractions of a cent per execution, so ongoing costs are negligible.

Resources you used:

Resource group: nsg-logicapp-rg (contains all project resources).
Virtual Network: demo-vnet with app-subnet (free).
Network Security Group: demo-nsg associated with app-subnet (free).
Consumption Logic App: nsg-access-controller with system-assigned managed identity (fractions of a cent per execution).
RBAC role assignment: Network Contributor role on demo-nsg granted to the Logic App's managed identity.

Keep everything running

No action needed. Choose this if you are still actively building or want to experiment further with the Logic App workflow.

The Logic App continues running once daily at 8:00 AM. Costs remain negligible.
The DenyAllInternetInbound rule stays active on the NSG, blocking all inbound internet traffic to app-subnet.
If you want to allow internet traffic again, navigate to demo-nsg, go to Settings > Inbound security rules, select the DenyAllInternetInbound rule, and delete it.

Pause - I'll come back to this later

Disable the Logic App to stop the daily runs while preserving your entire setup for later.

In the Azure portal, navigate to your nsg-access-controller Logic App.
On the Overview page, select Disable.
This stops all scheduled runs. The VNet, NSG, and role assignment remain intact so you can re-enable the Logic App anytime.
A disabled Logic App incurs no execution costs.

Delete - I don't want to use this again

Remove all project resources at once by deleting the resource group. This is the cleanest way to ensure nothing is left behind.

In the Azure portal, search for Resource groups.
Select nsg-logicapp-rg.
Select Delete resource group.
Type nsg-logicapp-rg to confirm, then select Delete.
This removes the VNet, NSG, Logic App, managed identity, and the RBAC role assignment all at once.

Mission accomplished

That's a Wrap!

Nice work! You just built an automated network security controller using Azure Logic Apps. Your workflow checks the calendar every day and locks down internet access to your subnet the moment a cutoff date arrives.

Here's what you learned:

Created a Virtual Network, subnet, and Network Security Group as the networking foundation for automated access control.
Built a Consumption Logic App that authenticates to the Azure REST API using a managed identity with no stored credentials.
Configured a daily schedule with a date-based condition that automatically applies a Deny rule to the NSG when the cutoff date passes.
Added email notifications so you have an audit trail every time the Logic App blocks internet traffic.

Ready to quiz yourself?