Cloud Security for SMEs: The Most Common Misconfigurations and How to Avoid Them

TL;DR

Over 80 percent of all cloud security incidents are caused by misconfigurations, not sophisticated attacks. The biggest risks are preventable.
The shared responsibility model means: the cloud provider secures the infrastructure, but you are responsible for configuration, access management, data protection, and compliance.
The ten most common misconfigurations include open storage accounts, missing MFA, overly broad permissions, disabled logging, missing encryption, default credentials, missing network policies, unused resources, missing backups, and no monitoring.
Microsoft Secure Score, Azure Advisor, and Defender for Cloud provide free or low-cost tools that SMEs can use immediately to assess and improve their cloud security.
A monthly cloud security review with a structured checklist is the most pragmatic approach for SMEs without a dedicated cloud security team.

The Cloud Is Secure — Your Configuration Is Not

When an organization suffers a data loss in the cloud, the first reaction is often: "The cloud is insecure." The opposite is true. The major cloud providers operate their infrastructure at a security level that no mid-sized company could even remotely achieve in their own data center. Thousands of security engineers, military-grade physical security, redundant data centers across multiple continents, permanent monitoring.

The problem almost never lies with the cloud infrastructure itself. It lies with the configuration. Gartner predicts that by 2027, over 99 percent of all cloud security incidents will be attributable to customer error — and current figures confirm this trend. Open storage containers, missing multi-factor authentication, administrator rights for all users, disabled logging. These are not exotic vulnerabilities. These are configuration errors that happen every day and can be avoided with manageable effort.

For SMEs, the cloud is long since reality: Microsoft 365 is virtually standard, Azure services are used for hosting, backup, and applications, and SaaS solutions are replacing local software. But security competence has not always kept pace with cloud adoption. Many SMEs have "carried over" their on-premises IT expertise to the cloud without recognizing that cloud security follows different rules.

Understanding the Shared Responsibility Model

The shared responsibility model is the foundation of cloud security — and misunderstanding it is the cause of most problems. It defines who is responsible for which part of security.

The cloud provider is responsible for: The physical security of the data centers, the security of the hardware and virtualization layer, the availability and resilience of the infrastructure, the security of the network infrastructure, and the basic platform security.

You are responsible for: The configuration of all services you use, access and permission management, the security of your data (encryption, classification, backup), network configuration within your cloud environment, monitoring and detection of security incidents, compliance with regulatory requirements, and securing the endpoints that access cloud services.

The boundary shifts depending on the service model: with Infrastructure as a Service (IaaS), you bear the most responsibility. With Platform as a Service (PaaS), the provider assumes more. With Software as a Service (SaaS), the provider's responsibility is highest — but even with SaaS, you remain responsible for access management, configuration, and data.

A practical example: when you use Microsoft 365, Microsoft ensures that Exchange Online is available and the servers are securely operated. But Microsoft does not ensure that your users have MFA enabled, that the sharing settings in SharePoint don't invite the whole world, or that former employees no longer have access. That is your responsibility.

The Ten Most Common Misconfigurations

The following ten misconfigurations are ones we regularly encounter when working with mid-sized organizations. Each one individually can lead to a security incident. Together, they paint a picture that is unfortunately typical.

1. Open Storage Accounts and Containers

The problem: Azure Storage Accounts, AWS S3 Buckets, or other cloud storage are configured with public access — either intentionally ("we need this for data exchange") or accidentally. The result: anyone who knows the URL can access the stored data. And automated scanners continuously search the internet for such open containers.

The list of incidents is long: millions of customer records, patient files, ID copies, and financial reports found in open cloud storage. In many cases, the data was exposed for months before the error was discovered.

The solution: By default, no storage account should be publicly accessible. Azure has offered since 2023 the ability to disable public blob access at the subscription level. Activate this setting. For cases where data actually needs to be shared externally, use Shared Access Signatures (SAS) with expiration dates and restricted permissions or Azure Private Links.

Regular review: use Azure Policy to identify storage accounts that allow public access. A monthly scan with Azure Advisor or a CSPM tool automatically uncovers misconfigurations.

2. Missing Multi-Factor Authentication

The problem: MFA is disabled or not mandatory for all users. This affects both regular user accounts and — particularly critically — administrator accounts. Without MFA, stolen or guessed credentials are sufficient to gain full access.

The numbers speak clearly: Microsoft reports that over 99.9 percent of all compromised accounts did not have MFA enabled. MFA is the single most effective measure against account takeover.

The solution: Enable MFA for all users, without exception. In Microsoft 365 and Azure AD, there are Security Defaults (free and activatable with one click) or Conditional Access Policies (for more differentiated requirements). Minimum standard: MFA for all administrators, for all access from outside the corporate network, and for all access to sensitive applications.

For administrator accounts, MFA should not just be enabled but enforced — without the option to bypass or defer it. And do not use SMS as the second factor for admin accounts; use TOTP apps or, better yet, FIDO2 hardware keys.

3. Overly Broad Permissions

The problem: Users and applications have more permissions than they need. The classic pattern: a user needs read access to a resource and instead receives the "Owner" or "Contributor" role on the entire subscription. Or a service principal for an application gets global administrator rights because "it worked that way."

In Azure and M365, we regularly see too many Global Admins (there should be a maximum of two to four), broad role assignments at the subscription level instead of the resource level, service principals with unnecessary permissions, and guest accounts with access to internal resources that are no longer needed.

The solution: Consistently apply the least privilege principle. In Azure, this means: assign roles at the lowest possible level (resource group instead of subscription). Use built-in roles instead of custom roles with overly broad permissions. Reduce the number of Global Admins. Conduct quarterly access reviews, which Azure AD natively supports.

For administrators: use Privileged Identity Management (PIM) to activate admin rights only when needed and time-limited (just-in-time access). An administrator who only activates their elevated rights when needed for a maximum of four hours poses a significantly lower risk than a permanently privileged account.

4. Disabled or Insufficient Logging

The problem: Audit logging and diagnostic logging are not enabled, or logs are not retained and analyzed. Without logs, you can neither detect whether a security incident occurred nor reconstruct what happened after the fact.

In Microsoft 365, the Unified Audit Log is enabled by default, but the retention period in the standard license is only 180 days. In Azure, many diagnostic logs are not active by default and must be configured per resource. And even when logs exist, they are not analyzed in many SMEs — meaning a security incident is only noticed after the damage has already occurred.

The solution: At minimum, enable the Unified Audit Log in Microsoft 365 with maximum retention (365 days with E5 license, otherwise 180 days). In Azure, enable Azure Activity Log and diagnostic logs for all critical resources (network security groups, Key Vaults, storage accounts, SQL databases).

Forward logs to a central location: Azure Log Analytics Workspace, a SIEM system, or at minimum a dedicated storage account with an immutability policy so that logs cannot be tampered with or deleted. Define basic alerting rules for the most obvious warning signs: mass failed login attempts, admin actions outside business hours, changes to security groups and conditional access policies.

5. Missing Encryption

The problem: Data is not or insufficiently encrypted, neither at rest nor in transit. Azure does encrypt storage data by default with Microsoft-managed keys, but for many compliance requirements this is not sufficient. And encryption during transfer between services or to external partners is often overlooked.

Particularly critical: databases without Transparent Data Encryption (TDE), VM disks without Azure Disk Encryption, data transfers over unencrypted protocols, and backup data without encryption.

The solution: Enable encryption consistently at all levels. In Azure: TDE for all SQL databases (enabled by default but should be verified), Azure Disk Encryption for all VMs, enforce encryption in transit (HTTPS Only for storage accounts, TLS 1.2 minimum for all services).

For higher security requirements or regulatory compliance: use Customer-Managed Keys (CMK) via Azure Key Vault instead of Microsoft-Managed Keys. This gives you control over the encryption keys and the ability to revoke access if needed.

6. Default Credentials and Weak Passwords

The problem: Newly provisioned services retain their default credentials, or weak passwords are assigned. This particularly affects VMs, databases, network devices, and IoT devices operated in the cloud. Automated scanners permanently test known default credentials and regularly find open doors.

The solution: Enforce strong passwords through Azure AD Password Protection, which blocks known weak passwords and custom banned passwords. For service accounts and applications: use Managed Identities in Azure, which require no passwords and are automatically rotated. For cases where passwords or secrets are unavoidable: store them in Azure Key Vault with automatic rotation — not in code, configuration files, or documents.

Create an inventory of all services and check whether default credentials have been changed. This risk is particularly high with quickly provisioned test or development environments that accidentally become production.

7. Missing Network Policies

The problem: Network Security Groups (NSGs) are configured too openly, services are reachable from the internet that shouldn't be, and network segmentation is insufficient. The classic: a VM with an open RDP port (3389) or SSH port (22) to the internet, which is found and attacked by automated scanners within hours.

The solution: No service should be directly reachable from the internet without necessity. Use Azure Bastion for administrative access to VMs instead of open RDP/SSH ports. Configure NSGs using the deny-all principle and only open the actually required ports and protocols. Use Service Endpoints and Private Endpoints to isolate Azure services (Storage, SQL, Key Vault) from the public internet.

For network segmentation in Azure: separate workloads into different Virtual Networks or Subnets and control traffic between them via NSGs and Azure Firewall. Production, development, and test environments should run in separate subscriptions or at least in isolated networks.

8. Unused and Forgotten Resources

The problem: Test environments not decommissioned after testing. VMs created for a project and forgotten after the project ended. Service principals and app registrations no longer needed. Storage accounts with old data that nobody remembers. Every unused resource is a potential attack surface that is not maintained, not patched, and not monitored.

The solution: Conduct a regular inventory of all cloud resources. Azure Resource Graph enables queries across all subscriptions and helps identify forgotten resources. Use tags to associate resources with an owner, a project, and an expiration date. Resources without an owner or with an expired date are reviewed and potentially deleted.

Azure Advisor automatically identifies unused resources (idle VMs, empty resource groups, orphaned network interfaces) and provides recommendations. Make the Azure Advisor review a fixed part of your monthly cloud review.

9. Missing or Untested Backups

The problem: There is no backup concept for cloud data, or backups exist but have never been tested. Many organizations assume the cloud provider handles backups — which is a dangerous misunderstanding of the shared responsibility model.

Microsoft 365 does offer recycle bins and versioning, but the retention periods are limited and insufficient for a real backup strategy. Azure VMs are not automatically backed up. And data in SaaS applications is subject to the shared responsibility model: the provider ensures platform availability; you ensure your data is backed up.

The solution: Implement an explicit backup strategy for all cloud data. For Azure VMs: Azure Backup with defined backup policies (frequency, retention period, geo-redundancy). For Microsoft 365: a dedicated M365 backup solution (Veeam, AvePoint, Microsoft 365 Backup) that covers Exchange, SharePoint, OneDrive, and Teams.

And the most important point: test recovery regularly. A backup that doesn't work in an emergency is worthless. Plan quarterly restore tests for the most critical data and document the results.

10. No Active Monitoring and Alerting

The problem: Cloud services are provisioned and running, but nobody actively monitors security events. There are no alerts, no dashboards, and no defined process for responding to security indicators. Microsoft's security features (Defender for Cloud, Secure Score, alerts) are available but unused.

The solution: As a first step, enable Microsoft Defender for Cloud (free tier) and review the recommendations. The Microsoft Secure Score provides a number summarizing the current security status of your M365 environment and gives concrete improvement suggestions.

Define alerting rules for the most critical events: new Global Admin assignments, changes to conditional access policies, mass login attempts, suspicious sign-in activities (impossible travel, logins from known attacker networks), and changes to firewall rules. These alerts should go to a defined team that can respond promptly.

For SMEs without a dedicated SOC: a weekly review of security events and monthly review of security recommendations in Defender for Cloud and Azure Advisor is a realistic, practical approach.

Cloud Security Posture Management (CSPM)

Cloud Security Posture Management describes the continuous process of evaluating the security configuration of your cloud environment, identifying deviations from best practices, and remediating misconfigurations. It is essentially the answer to the question: "How do I ensure that my cloud configuration stays secure over time?"

Tools for SMEs

Microsoft Secure Score: Free in every M365 environment. Evaluates the security configuration of your M365 services and provides prioritized recommendations. The score ranges from 0 to 100 percent. A realistic target for SMEs is 70 to 80 percent.

Azure Advisor: Free and available in every Azure portal. Provides recommendations in the categories of security, reliability, performance, cost, and operational excellence. The security recommendations are based on Azure Security Benchmark and cover the most common misconfigurations.

Microsoft Defender for Cloud: The free tier provides basic security assessments. The paid plans (Defender for Servers, Defender for Storage, etc.) extend protection with vulnerability scanning, threat detection, and advanced recommendations. For SMEs with a limited number of Azure resources, costs remain within a reasonable range.

Azure Policy: Enables enforcement of configuration standards at the subscription level. You can define policies that enforce certain configurations (for example: all storage accounts must require HTTPS) or prevent others (for example: no VMs without disk encryption). Azure Policy works preventively and prevents misconfigurations before they occur.

The Monthly Cloud Security Review

For SMEs without a dedicated cloud security team, we recommend a monthly structured review covering the following points:

Check Secure Score: Has the score changed? Are there new recommendations? Which quick wins can be implemented immediately?
Review Azure Advisor security recommendations: Are there new recommendations? Which ones are high priority?
Conduct access review: Are there new admin accounts? Do departed employees still have access? Are there guest accounts that are no longer needed?
Evaluate security events: Were there suspicious sign-in activities? Were security alerts triggered? Were configuration changes made that weren't planned?
Check resource inventory: Are there new resources that aren't tagged? Are there unused resources that should be decommissioned?
Check backup status: Are all backup jobs running successfully? When was the last restore test?

This review takes approximately two to four hours per month and is therefore realistically achievable even for small IT teams. Document the results and the measures taken for your ISMS. In ISMS Lite, cloud security reviews can be set up as recurring tasks and the results linked directly to the risk register.

Practical Tips for Microsoft 365 and Azure

The following measures can be implemented in most M365 and Azure environments within a few hours and address the most common risks.

Microsoft 365

Activate Security Defaults (if not already done): one click in the Azure AD portal enables MFA for all users, blocks legacy authentication, and enforces MFA for administrators.
Restrict external sharing in SharePoint: By default, users can share content with anyone. Restrict sharing to authenticated guests and disable anonymous link sharing.
Extend audit log retention: In compliance settings, set the maximum retention period for audit logs.
Enable Safe Attachments and Safe Links: These Defender for Office 365 features check attachments in a sandbox and URLs in real time. Available from the Business Premium plan.
Set up Conditional Access (if P1 or P2 license is available): enforce MFA for access from outside the corporate network, block legacy protocols, restrict sign-ins from high-risk countries.

Azure

Activate Azure Security Benchmark: Assign the "Azure Security Benchmark" initiative in Azure Policy. It automatically checks compliance with Microsoft security recommendations and displays the compliance status.
Management Locks on critical resources: CanNotDelete locks on production resource groups prevent accidental deletion.
Configure Diagnostic Settings for all critical resources: NSGs, Key Vaults, Storage Accounts, and Application Gateways should send their logs to a Log Analytics Workspace.
Enable Just-in-Time VM Access: Instead of keeping VMs permanently open with management ports, JIT opens access only when needed and only for the requesting IP address.
Configure budget alerts: Unusual cost spikes can indicate compromised resources (for example, cryptomining on hijacked VMs). Budget alerts warn of unexpected cost increases.

Cloud Security in the ISMS

ISO 27001 explicitly addresses cloud security in control A.5.23 (Information security for use of cloud services). Additionally, numerous other controls are relevant for the cloud environment:

A.5.15 to A.5.18 (Access control): Permission management in Azure AD
A.8.1 (User endpoint devices): Securing devices that access cloud services
A.8.9 (Configuration management): Security configuration of cloud services
A.8.10 (Information deletion): Data deletion in the cloud and at contract termination
A.8.11 (Data masking): Protection of sensitive data in cloud environments
A.8.13 (Information backup): Backup strategy for cloud data
A.8.15 and A.8.16 (Logging and monitoring): Monitoring the cloud environment

Integrating cloud security into your ISMS requires extending your risk register with cloud-specific scenarios, documenting responsibilities according to the shared responsibility model, incorporating configuration standards for cloud services into your policies, and anchoring the regular cloud security review as a process in the ISMS.

For SMEs, we recommend a pragmatic approach: start with the ten misconfigurations from this article as a checklist. Fix the most critical items first. Establish the monthly review. And gradually expand the measures as you gain experience and cloud usage grows.

Cloud security is not a project with an end date but a continuous process. The cloud landscape constantly changes: new services are added, configuration options change, and new threats require adapted measures. An ISMS that integrates cloud security as a permanent component gives you the framework to manage these changes in a structured and demonstrable way.