“Corsica is a one-stop shop for us. If I have a problem, I can go to my vCIO or a number of people, and you take care of it. That’s an investment in mutual success.”
It takes dedicated experience to use technology strategically in your industry. That’s why we specialize in certain verticals while offering comprehensive technology services.
Cloud Technology, Cybersecurity, Microsoft Security
Whether you’re migrating to Microsoft Azure or securing an existing environment, it’s crucial to establish the right security controls in Azure. While Microsoft provides platform-level protection out of the box, customers need to configure additional security controls to meet their needs in terms of operations, security posture, and compliance.
So, which best practices should you follow for Azure security?
We’ve got all the answers below.
Key takeaways:
Microsoft provides strong security for Azure at the platform level, but customers usually need to implement additional controls to satisfy their requirements.
Data in Azure is secured by default, both at rest and in transit, but customers should configure policies, key ownership, and access to align with their requirements.
Azure supports common compliance frameworks at the platform level, but organizations will need to move beyond default configurations to support compliance efforts.
Microsoft Entra ID provides strong identity and access controls for Azure environments.
Microsoft Defender for Cloud and Microsoft Sentinel can provide threat detection and correlation within your Azure environment.
Microsoft Azure is secure by default at the platform level, but customers must actively configure and manage Azure security controls to fully protect their workloads. Some customers engage internal staff to handle these responsibilities, while others choose to engage cloud management services from an MSP or MSSP.
Azure is built on a highly secure global cloud infrastructure with strong baseline protections built in, such as:
Physical datacenter security
Encrypted communications
Identity safeguards
Continuous monitoring by Microsoft
However–and this is critical to understand–Azure follows a shared responsibility model, meaning Microsoft secures the cloud itself, while customers are responsible for properly securing what they deploy in the cloud.
What is the shared responsibility model for security in Azure?
The shared responsibility model for security in Azure defines how security responsibilities are divided between Microsoft and the customer. Microsoft is responsible for securing the Azure cloud platform itself, including physical datacenters, hardware, networking, and the underlying infrastructure, while customers are responsible for securing what they deploy in the cloud, such as identities, access controls, operating systems, applications, data, and configurations.
Here’s what that looks like in detail.
What Microsoft secures by default in Azure
Microsoft is responsible for securing the underlying Azure platform and services, including:
Baseline encryption for data in transit and many services at rest
Built‑in identity protections via Microsoft Entra ID (formerly Azure AD)
Platform threat detection and global intelligence from Microsoft Security
These controls mean Azure’s foundational environment typically exceeds what most organizations can implement on‑premises in terms of baseline security.
What Microsoft Azure customers must configure themselves to ensure security
Many of Azure’s most important security controls are available but not enforced by default, including:
Multi-factor authentication (MFA) enforcement for users and admins
Least-privilege access with Azure RBAC and role scoping
Network exposure controls, such as private endpoints, firewalls, and segmentation
Workload hardening for VMs, containers, apps, and databases
Security monitoring and posture management using tools like Defender for Cloud
Key takeaway: If these are left unconfigured, environments can still be vulnerable even though they’re running on a secure platform.
Is data encrypted in Azure?
Yes, data in Microsoft Azure is encrypted by default, both at rest and in transit, with multiple options for customers to control how encryption is implemented and managed. Azure uses industry‑standard encryption technologies across its services to help protect customer data from unauthorized access, whether the data is being stored, processed, or transmitted between systems.
How Azure encryption works for data at rest
Azure encrypts data stored in its services in several ways.
Infrastructure‑level encryption protects disks, storage, and databases using strong encryption (typically AES‑256).
Most core services, such as Azure Storage, Azure SQL Database, Managed Disks, and Cosmos DB, have encryption at rest enabled by default, with no customer action required.
Customer Managed Keys (CMK) are supported for many services, allowing organizations to control their own encryption keys rather than relying on Microsoft‑managed keys.
This ensures data remains unreadable if storage media is accessed or compromised.
How Azure encryption works for data in transit
Azure also protects data as it moves between systems:
TLS (Transport Layer Security) is used to encrypt data in transit between Azure services, users, and on‑premises systems.
Secure communication is enforced for service endpoints, APIs, and administrative access.
Customers can require encrypted connections for applications, storage accounts, and databases to prevent data interception.
Key management and customer control
While encryption is turned on by default, Azure offers flexibility for organizations with advanced security or compliance needs. There are several ways customers can address these requirements.
Microsoft‑managed keys (default) reduce complexity and operational overhead.
Customer‑managed keys (CMK) stored in Azure Key Vault or Azure Cloud HSM provide greater control, auditability, and key rotation.
Bring Your Own Key (BYOK) scenarios are supported for certain services and compliance frameworks.
The bottom line on Azure data encryption
Azure encrypts data by default to provide a secure baseline, but customers can (and should) configure encryption policies, key ownership, and access controls to align with their organization’s security posture and compliance requirements.
Is Azure secure enough for regulated data?
Yes, Microsoft Azure is widely considered secure enough for regulated data, provided Azure resources are configured and governed correctly. Azure is designed to support sensitive and regulated workloads such as those found in healthcare, financial services, government, and defense. The platform does so by offering strong security controls, extensive compliance certifications, and enterprise‑grade data protection.
However, using Azure does not automatically make data compliant with a specific regulatory framework. Organizations must still apply appropriate security, governance, and operational controls.
Is Azure compliant with HIPAA, SOC 2, ISO 27001, PCI DSS, or CMMC?
Yes, at the platform level, Microsoft Azure is formally compliant with HIPAA, SOC 2, ISO/IEC 27001, PCI DSS, and other frameworks. The platform also supports customers pursuing CMMC. However, compliance depends on how specific workloads and services are used, configured, and secured in Azure. Customers are still responsible for implementing required security, governance, and operational controls to meet their own regulatory obligations.
Common Azure security controls that help with compliance
Security Control Area
HIPAA
SOC 2
ISO/IEC 27001
PCI DSS
CMMC
Identity & Access Management (RBAC
✅
✅
✅
✅
✅
Multi-Factor Authentication (MFA)
✅
✅
✅
✅
✅
User & Admin Account Monitoring
✅
✅
✅
✅
✅
Network Security & Segmentation
✅
✅
✅
✅
✅
Encryption at Rest
✅
✅
✅
✅
✅
Encryption in Transit (TLS)
✅
✅
✅
✅
✅
Customer-Managed Keys / Key Control
◐
◐
✅
✅
✅
Centralized Logging & Audit Trails
✅
✅
✅
✅
✅
Continuous Security Monitoring
◐
✅
✅
✅
✅
Vulnerability Management & Patching
✅
✅
✅
✅
✅
Configuration Hardening / Baselines
✅
✅
✅
✅
✅
Incident Response Plan & Testing
✅
✅
✅
✅
✅
Backup, Recovery & Business Continuity
✅
✅
✅
✅
✅
Data Classification & Handling Policies
✅
◐
✅
✅
✅
Compliance Evidence & Reporting
✅
✅
✅
✅
✅
Legend
✅ = Explicitly required
◐ = Required or expected depending on scope, data type, or maturity level
How this maps to Azure controls
These framework‑level requirements are typically implemented in Azure using:
Microsoft Entra ID (formerly Azure AD) – identity, MFA, conditional access
Azure RBAC & Azure Policy – least privilege, governance, enforcement
Azure Key Vault / Azure Cloud HSM – key management and encryption control
Microsoft Defender for Cloud – posture management and threat detection
Azure Monitor, Log Analytics, Microsoft Sentinel – logging, auditing, SIEM
Azure Backup, Azure Site Recovery, Azure regional and zonal location settings – availability and business continuity.
What are best practices to protect Microsoft Azure from misconfigurations?
Protecting Microsoft Azure from misconfigurations requires proactive governance, enforced security baselines, and continuous monitoring rather than relying on default settings alone. Most Azure security incidents stem from human error, such as overly permissive access, exposed endpoints, and disabled or unreviewed logging. Consequently, the goal is to prevent unsafe configurations up front, detect drift quickly, and remediate automatically whenever possible.
Best practices to prevent misconfigurations in Azure
Enforce identity-first security
Lock down network exposure
Standardize and enforce configurations with policy
Continuously assess security posture and remediate
Centralize logging and monitoring in Microsoft Sentinel
Proactive misconfiguration detection with Microsoft Defender for Cloud
Harden deployments through automation such as templates and pipelines
Encrypt data by default
Apply secure baselines
How does Microsoft Entra ID secure user identities in Azure?
Microsoft Entra ID (formerly Azure Active Directory) secures user and service principal identities by centralizing authentication, enforcing strong access controls, and continuously evaluating risk before granting access to cloud and on‑premises resources. Entra ID acts as Azure’s identity control plane, protecting users, administrators, and applications through layered defenses that combine strong authentication, conditional access, and continuous monitoring aligned with Zero Trust principles.
Prevents account compromise from stolen or guessed credentials
Conditional Access
Grants or blocks access based on user, device, location, risk, and application
Enforces Zero Trust by adapting security to real‑time risk
Role‑Based Access Control (RBAC)
Assigns permissions based on roles rather than individual users
Enforces least privilege and reduces excessive access
Privileged Identity Management (PIM)
Provides just‑in‑time, time‑limited admin access with approvals
Minimizes standing admin privileges and insider risk
Passwordless Authentication
Supports sign‑in without passwords (FIDO2, Authenticator, biometrics)
Eliminates password‑based attack vectors
Identity Protection
Detects risky sign‑ins and compromised credentials using threat intelligence
Identifies and mitigates identity threats early
Single Sign‑On (SSO)
Centralizes authentication across Azure and SaaS applications
Reduces credential sprawl and improves access visibility
Device‑Based Access Controls
Evaluates device compliance and health during sign‑in
Prevents access from unmanaged or compromised devices
Access Reviews
Periodically reviews and certifies user access to resources
Prevents permission creep and orphaned access
Audit Logs & Sign‑In Logs
Records authentication events, access changes, and identity actions
Enables monitoring, forensics, and compliance evidence
Do I need multi-factor authentication (MFA) for Azure, and how is it enforced?
Yes! Multi‑factor authentication (MFA) is the #1 most strongly recommended best practice for Microsoft Azure. This control is effectively required for any environment that needs to meet modern security or compliance standards. Azure does not technically force MFA on all users by default, but Microsoft Entra ID (formerly Azure Active Directory) provides multiple built‑in mechanisms to require, enforce, and adapt MFA based on user role, risk, and context.
In practice, running Azure securely without MFA—especially for administrators—is considered a critical security gap.
MFA in Azure is enforced primarily through Entra ID Conditional Access policies, which allow organizations to define when and for whom MFA is required. Policies can mandate MFA for all users, specific groups, privileged roles, or access to sensitive applications and resources. Enforcement can also be contextual, for example, requiring MFA only when users sign in from unmanaged devices, unfamiliar locations, or high‑risk sessions. This approach aligns with Zero Trust principles by verifying identity continuously rather than relying on a one‑time login.
Azure also enforces MFA more strictly for privileged and high‑risk accounts. Using Privileged Identity Management (PIM), administrators must complete MFA before activating elevated roles, and that access is time‑bound and auditable. Additionally, Microsoft applies Security Defaults for many tenants, which automatically require MFA for administrators and block legacy authentication protocols that can’t support MFA. These protections significantly reduce the most common attack vector in cloud breaches: Compromised admin credentials.
What are best practices to detect threats or suspicious behavior in Azure?
Cloud administrators can detect threats or suspicious behavior in Azure by combining Microsoft-native security services that monitor identity activity, configuration risk, network traffic, workloads, and logs—then correlating those signals centrally for alerting and response. Microsoft provides built‑in tools that continuously analyze behavior using threat intelligence, baselines, and anomaly detection, while giving customers control over what is monitored, how alerts are generated, and how incidents are investigated or escalated.
Here are the various Azure services that can assist with different types of threat detection.
Improves detection accuracy and reduces false positives
Automated Alerting & Response
Sentinel Automation & Playbooks
High‑confidence security incidents
Accelerates response and reduces manual effort
The takeaway: Configure Azure security to meet your organization’s needs
Azure supports a wide range of security controls that can easily meet your needs. The challenge is configuring your settings properly and maintaining security over the long haul. If you need assistance, the Corsica Technologies team is here to help. We are a long-standing, proven Microsoft Solutions Partner for Security with specializations in Azure Infrastructure, Cloud Security, Identity and Access Management, and Threat Protection. We are also a member of the Microsoft Intelligent Security Association (MISA). Contact us today, and let’s get started on your Azure security journey.
John is Senior Director of Technology at Corsica Technologies. Awarded Microsoft MVP for 18 years (2007-2026), he is currently dual-awarded in Azure Management and Cloud Security. He is a certified Azure Solutions Architect Expert and Microsoft Cybersecurity Architect Expert. John co-authored the four books in the industry-standard reference series, System Center Operations Manager: Unleashed (Sams publishing). His most recent book ‘Azure Arc-Enabled Kubernetes and Servers’ was published by Apress. Specialties include Microsoft Sentinel/Defender XDR, Security Copilot, Defender for Cloud, Defender for IoT, Azure Monitor, and Azure Arc. He is a retired U.S. Navy Lt. Commander who served as Chief of Network Operations for NATO southern region and national Network Security Officer for the Navy Bureau of Personnel.
Ready to take your next step?
Contact us today to get the outside perspective you need for the next step on your journey.
