10 Important Azure Security Settings That Are Easy to Miss

Mona — Sun, 31 May 2026 19:28:27 +0000

When learning Azure security, I realized that many important security controls are already available in the platform but are easy to overlook during deployment and configuration.

To better understand Azure security, I reviewed several identity, networking, secrets management, monitoring, and security posture settings within my lab environment. Throughout this process, I identified a number of commonly overlooked configurations that could increase security risk if left unchecked.

In this article, I share 10 important Azure security settings that I explored, why they matter, how I verified them, and recommendations for improving overall security posture.

1. Multi-Factor Authentication (MFA) Not Enforced

Mistake
One of the first things I checked was whether multi-factor authentication was enforced for user accounts. It is easy to assume that strong passwords alone provide sufficient protection.

Risk
If a user's password is compromised through phishing, password reuse, or credential theft, an attacker may be able to access Azure resources without additional verification.

How I Verified

Open Azure Portal.
Navigate to Microsoft Entra ID.
Select Users.
Open a user account.
Click Authentication Methods.

Fix
Enable MFA for all users, especially privileged accounts, and regularly review authentication methods.

Screenshot

2. Excessive Owner Permissions (RBAC)

Mistake
During my lab setup, I initially assigned Owner permissions to simplify testing. While reviewing IAM settings later, I realized how easily excessive privileges can remain in place after deployment.

Risk
Users with excessive privileges can accidentally modify resources, delete services, or grant permissions to others. If an account is compromised, the impact can be significant.

How I Verified

Open Azure Portal.
Navigate to Subscriptions.
Select the subscription.
Open Access Control (IAM).
Click Role Assignments.
Filter by Owner.

Fix
Apply the Principle of Least Privilege by assigning only the permissions required for a user's responsibilities.

Screenshot

3. Secrets Stored Outside Key Vault

Mistake
Application credentials and connection strings are sometimes stored directly in configuration files because it is convenient during development.

Risk
Secrets stored in files or repositories may be exposed through source control, backups, or unauthorized access.

How I Verified

Create an Azure Key Vault.
Open Key Vault.
Navigate to Secrets.
Click Generate/Import.
Create a test secret.
Confirm the secret is stored centrally within Key Vault.

Fix
Store passwords, API keys, and connection strings in Azure Key Vault.

Screenshots

4. Key Vault Accessible from All Networks

Mistake
When I first created a Key Vault, I focused on storing secrets and almost overlooked the networking configuration.

Risk
If credentials are compromised, attackers may attempt access from any location.

How I Verified

Open Azure Portal.
Navigate to Key Vault.
Select the Key Vault.
Select Settings -> Networking.
Review Public Access settings.

Fix
Restrict Key Vault access using selected networks or private endpoints.

Screenshot

5. Resource Locks Not Configured

Mistake
Critical resources can be accidentally deleted.

Risk
Accidental deletion or unauthorized removal of critical resources could result in service disruption and data loss.

How I Verified

Open a resource.
Navigate to Locks.
Check for:
Delete Lock
Read Only Lock

Fix
Apply resource locks to critical assets.

Screenshot

6. Storage Account Public Network Access Enabled

Mistake
Storage accounts may allow access from any network unless networking restrictions are configured.

Risk
Exposed storage services increase the attack surface and may allow unauthorized access attempts.

How I Verified

Open Azure Portal.
Navigate to Storage Accounts.
Select a Storage Account.
Open Settings -> Configuration.
Review Public Network Access settings.

Fix
Restrict access to selected networks or use Private Endpoints where possible.

Screenshot

7. SSH Exposed to Internet

Mistake
When creating a virtual machine, allowing SSH access from any source is often the easiest option.

Risk
Internet-facing SSH services are continuously targeted by automated scans and brute-force attacks.

How I Verified
I reviewed Virtual Machine → Networking and checked inbound rules for Port 22.

Fix
Restrict SSH access to trusted IP addresses or use Azure Bastion.

8. Flat Network Design

Mistake
Placing all resources in a single subnet may seem simpler during deployment.

Risk
If one resource is compromised, attackers may move laterally to other systems more easily.

How I Verified
I reviewed Virtual Network subnet structures and associated Network Security Groups.

Fix
Separate workloads into dedicated subnets and apply security controls between them.

Screenshot

9. Missing Diagnostic Settings

Mistake
Resources can function normally even when diagnostic logging is not configured.

Risk
Troubleshooting and security investigations become much harder without historical logs.

How I Verified
I reviewed Diagnostic Settings for Azure resources and checked whether logs were being sent to a monitoring destination.

Fix
Configure diagnostic settings and send logs to Log Analytics, Storage Accounts, or Event Hub.

Screenshot

10. Security Recommendations Not Reviewed

Mistake
Security recommendations are easy to ignore after resources are deployed.

Risk
Unresolved security recommendations can increase exposure to known security risks and reduce overall security posture.

How I Verified
I reviewed Microsoft Defender for Cloud recommendations and Secure Score to understand the current security posture.

Fix
Review recommendations regularly and prioritize high-impact findings.

Screenshot

Final Thoughts

One of the biggest lessons I learned while reviewing Azure security settings is that many security risks originate from small configuration decisions rather than sophisticated attacks.

Identity management, permissions, networking, secrets management, monitoring, and security posture all play an important role in protecting cloud environments. Regularly reviewing these settings can help identify gaps early and improve overall security posture.

Security is not a one-time task. It is an ongoing process of verification, monitoring, and continuous improvement.

Installing Prowler on Azure – My Hands-On Learning Experience

Mona — Sat, 16 May 2026 04:55:00 +0000

Recently, I integrated Prowler to better understand how cloud security scanning tools help secure cloud deployments in real environments. I explored both the GUI and CLI versions on Azure to understand how each approach works for security scanning, identifying compliance gap and reporting.
This blog focuses on my initial hands-on experience with the Prowler setup on Azure Cloud Shell.

# What is Prowler?

Prowler is an open-source cloud security assessment tool used to scan cloud environments for:

Security misconfigurations
Risky settings
Compliance gaps
Exposed cloud resources

It supports multiple cloud platforms:

Amazon Web Services(AWS)
Microsoft Azure
Google Cloud Platform (GCP)

Prowler can be used in two ways:

CLI(Command Line Interface)
GUI/Web Dashboard

# Installing Prowler on Azure

Below are the basic steps I followed during the setup process.

Step 1 — Open Azure Cloud Shell

Login to your Microsoft Azure account
From the top menu → click Cloud Shell icon [>_]
Select Bash Azure Cloud Shell already includes Azure CLI, which makes the setup process easier.

Step 2 — Install Prowler (in Cloud Shell)
Run the following commands:
python3 -m pip install --user pipx
python3 -m pipx ensurepath
pipx install prowler

Check the installation:
prowler -v

Step 3 — Run First Scan
Check the active Azure subscription:
az account show --output table
Run the scan:
prowler azure --az-cli-auth
OR scan a specific subscription:
prowler azure --az-cli-auth --subscription-ids <YOUR-SUBSCRIPTION-ID>

This performs a security assessment of the Azure subscription and generates security findings and compliance results.

Step 4 — View the reports
After the scan completes, Prowler generates reports in multiple formats, such as:

HTML
JSON
CSV

The HTML report is especially useful for demonstrations and presentations because it provides a clean dashboard-style view of the scan results.

Final Thoughts

This was my first hands-on experience with Prowler, and it gave me a practical introduction to cloud security scanning and compliance validation. If you are starting with cloud security or DevSecOps, Prowler is a good tool to explore because it is open-source, beginner-friendly, and supports multiple cloud platforms.

DEV Community: Mona

10 Important Azure Security Settings That Are Easy to Miss

1. Multi-Factor Authentication (MFA) Not Enforced

2. Excessive Owner Permissions (RBAC)

3. Secrets Stored Outside Key Vault

4. Key Vault Accessible from All Networks

5. Resource Locks Not Configured

6. Storage Account Public Network Access Enabled

7. SSH Exposed to Internet

8. Flat Network Design

9. Missing Diagnostic Settings

10. Security Recommendations Not Reviewed

Final Thoughts

Installing Prowler on Azure – My Hands-On Learning Experience

# What is Prowler?

# Installing Prowler on Azure

Final Thoughts