The Question at Hand
When 3.6 million Azure account records are compromised, including data from major companies like McDonald's, who's accountable? Some argue cloud providers should secure their environments. Others believe it's an identity management issue that infrastructure hardening can't fix. This isn't just about assigning blame. Your answer affects where you invest your security budget, which controls you prioritize for SOC 2 CC6.1 (Logical and Physical Access Controls), and how you structure your ISO/IEC 27001 Clause 9.1 monitoring programs.
The Azure credential exposure highlights this tension. Security experts noted it wasn't a platform vulnerability but credential theft via infostealer malware. Your auditor will ask the same question your CISO is asking: if an attacker has valid credentials, what stops them?
The Case for Platform Responsibility
Some argue cloud providers should implement stronger guardrails to make credential-based attacks harder. Azure, AWS, and Google Cloud control authentication architecture and logging infrastructure. If directory enumeration is possible through a compromised credential, shouldn't the platform detect and block that pattern?
This perspective has compliance implications. When scoping SOC 2 trust services criteria, you rely on your cloud provider's SOC 2 Type II report. If Microsoft Azure notes exceptions around tenant isolation or directory access controls, that becomes your gap. You inherit the risk without controlling remediation. ISO/IEC 27001:2022 Annex A Control 5.19 requires addressing security within supplier agreements. If default settings allow broad directory queries, you're stuck negotiating terms you may not enforce.
Most organizations lack the expertise to configure cloud identity controls correctly. Conditional access policies and federated trust relationships are complex. Expecting every security team to master Azure AD architecture is unrealistic. Shouldn't the platform ship with secure defaults?
The Case for Internal Credential Management
The counterargument is straightforward: the cloud provider gave you the tools. If you didn't use them correctly, it's your failure, not Azure's. This isn't victim blaming; it's recognizing that identity is the one perimeter you control.
In the Azure incident, attackers used malware to harvest credentials from endpoints, then authenticated legitimately to Azure tenants. Microsoft didn't detect a breach because, from the platform's view, an authorized user logged in and performed allowed actions. The problem was that "authorized user" was an attacker with stolen credentials.
This is where SOC 2 CC6.2 (Prior to Issuing System Credentials and Granting System Access) and ISO/IEC 27001 Control 5.15 (Access Control) are critical. Both frameworks require defining access based on business need and enforcing least privilege. If a service account can enumerate your entire directory, you've granted excessive permissions. If a compromised credential provides access to export functions, you haven't implemented proper segregation of duties.
Credential theft happens outside the cloud environment. Infostealer malware runs on endpoints. Phishing attacks target users. Password reuse spans services. No amount of Azure hardening stops an attacker from stealing a password from a browser cache. The only defense is phishing-resistant multi-factor authentication, continuous session monitoring, and aggressive credential rotation. These are controls you implement, not Microsoft.
Where Practitioners Actually Land
Most security teams adopt a hybrid stance. They acknowledge cloud platforms could do more but don't wait for that to happen. They implement the controls they can enforce.
Operationally, this means configuring conditional access policies that require phishing-resistant MFA for administrative actions. Audit service principal permissions quarterly and remove unused ones. Monitor Azure AD sign-in logs for anomalies: geographic impossibilities, unusual directory queries, or session hijacking indicators. Treat privileged access management as a continuous process. These are the same controls your ISO/IEC 27001 Clause 9.1 program should track.
The Azure incident reinforces the importance of credential auditing beyond the cloud platform's tools. If an attacker compromised a credential six months ago, your Azure logs will show legitimate sign-ins. You need endpoint detection for infostealer activity before credentials are harvested. You need identity threat detection that flags directory enumeration even by authenticated users. You need a risk treatment plan that assumes credentials will be compromised.
Our Take
The cloud platform isn't the problem, but it's not the solution either. Blaming Azure for credential theft is pointless. Expecting Azure to compensate for poor identity hygiene is naive.
Your compliance program should reflect this reality. When designing SOC 2 CC6 controls, don't rely on your cloud provider's default settings. Implement phishing-resistant MFA as mandatory. During ISO/IEC 27001 internal audits, test whether your access controls would stop an attacker with valid credentials. Ask your team: if an employee's password was stolen today, what could an attacker access tomorrow? If the answer is "everything that employee can access," you have a control gap.
Organizations affected by the Azure credential exposure need to rotate secrets, audit service principals, and review federated trust relationships. But the real work is building an identity program that assumes credentials will be compromised and designs defenses around that assumption. That's not a cloud provider problem. It's your problem, and your auditor will expect you to solve it.
