Introduction: why a single tool is never enough
If you come from the Exchange or on-premises Active Directory world, you may have grown up with the idea that a good firewall and an up-to-date antivirus were enough to sleep soundly. In a Microsoft 365 and Azure environment, this logic no longer holds: security is distributed across identity, data, network, and applications, and each component depends on the others.
To make sense of it, an infographic widely shared in the IT community structures cybersecurity into twelve pillars, organized around a central core: the information system to be protected. Each pillar answers two simple questions: what scenario do I need to cover (Scenarios to Protect), and what concrete measures do I need to implement (Design Points)? This is the framework we will break down, pillar by pillar, with bridges to the Microsoft tools you already use.
Starting vocabulary
A "pillar" here is not a product to buy, it's a risk domain. A single pillar can be covered by multiple tools: for example, authentication relies on both Microsoft Entra ID (formerly Azure Active Directory, Microsoft's cloud identity service) and organizational policies.
The identity foundation: authentication and authorization
The first two technical pillars of the model — Authentication and Authorization — are deliberately placed at the foundation, because everything else depends on them.
Authentication answers a single question: "Are you really who you claim to be?" It's the equivalent of showing an ID card at the entrance of a building. The infographic recommends two concrete measures: a strong password policy and multi-factor authentication (MFA, which requires a second proof factor in addition to the password, such as a code sent to your phone). In the Microsoft ecosystem, this translates directly into conditional access policies from Microsoft Entra ID, which can require MFA depending on the sign-in context.
Authorization, on the other hand, answers a different question: "Once inside, what are you allowed to do?" To use the building analogy again, it's the badge that opens certain doors and not others — the analogy stops there, because in the cloud, these "doors" are logical resources (a mailbox, an Azure resource group, a SharePoint file) and not physical places. The model emphasizes three practices: regular review of rights, the principle of least privilege (granting only what's strictly necessary), and RBAC (Role-Based Access Control), which structures Azure permissions around predefined or custom roles rather than individual assignments.
Memory aid
Authentication = who you are. Authorization = what you can do. If you mix up these two terms in an interview or architecture documentation, it's a sign that you need to review the basics before digging deeper.
Protecting data, network, and applications
Once identity is secured, the model tackles the technical protection of the information system at large.
Encryption recommends using TLS (Transport Layer Security, the protocol that encrypts network exchanges, especially web traffic) for data in motion, encryption of sensitive data at rest, and rigorous management of encryption keys — this is precisely the role of Azure Key Vault, the Azure service dedicated to secure storage of secrets, keys, and certificates.
Vulnerability management relies on three reflexes: applying security patches without delay, regularly scanning your infrastructure for known flaws, and maintaining continuous monitoring. Audit and compliance complete this picture with regular audits, compliance with regulatory frameworks like GDPR (General Data Protection Regulation) or HIPAA (the U.S. health data privacy law), and exhaustive logging of events.
On the infrastructure side, four pillars complement each other:
- Network security: firewalls, network segmentation, intrusion detection, DNS security
- Endpoint security: disk encryption, antivirus, centralized device management
- Container security: trusted base images, runtime security controls
- API security: OAuth 2 protocol for delegated authorization, rate limiting, and strict input validation
In a modern Microsoft environment, these four domains directly overlap with the scope covered by Microsoft Defender for Endpoint, Defender for Cloud, and Defender for Cloud Apps, which centralize detection and response across these attack surfaces.
Operational resilience: disaster recovery and incident response
Security is not just about preventing intrusion: it must also ensure that you can survive if it happens.
Disaster Recovery requires a formalized plan, regular data backups, and system redundancy, to remain operational in case of ransomware attack or datacenter failure. This is the pillar most often neglected in SMEs, because it produces no visible value… until the day it saves one.
Emergency Responses require a documented incident response plan, a SOC (Security Operations Center, responsible for continuous monitoring and response), and regular exercises to test the plan in real-world conditions. A plan never tested is a plan that will fail at the first real incident — it's almost an empirical law of the industry.
Common pitfall
Many organizations confuse "having a backup" with "having a disaster recovery plan." A backup restores data; a disaster recovery plan restores a complete service, with predefined target times (RTO/RPO).
The human factor and the ecosystem: third-party management
The last pillar reminds us of an obvious truth too often forgotten: your attack surface doesn't stop at your own tenant. Third-Party Management covers vendor risk assessment, secure partner integration, and monitoring of external access.
This dimension relates to current concerns about securing the software supply chain, increasingly scrutinized in cloud environments where a misconfigured delegated access to a vendor can open a breach across your entire tenant.
Overview of the twelve pillars
To keep this model handy during an audit or architecture review, here's a condensed summary of the twelve pillars.
| Pillar | Scenario to Protect | Key Design Point |
|---|---|---|
| Disaster Recovery | Attacks, datacenter failures | Formalized plan, backups, redundancy |
| Authentication | User sign-in, employee access | Strong passwords, MFA |
| Authorization | Data access, user roles | Rights review, least privilege, RBAC |
| Encryption | Data in transit and at rest | TLS, key management |
| Vulnerability Management | Software flaws | Patches, scans, continuous monitoring |
| Audit and Compliance | Regulatory requirements | Regular audits, GDPR, HIPAA, logging |
| Network Security | Inbound and outbound traffic | Firewalls, segmentation, intrusion detection |
| Endpoint Security | Workstations | Disk encryption, antivirus |
| Emergency Responses | Security incidents | Response plan, SOC, exercises |
| Container Security | Application environments | Trusted images, runtime security |
| API Security | Data exchange interfaces | OAuth 2, rate limiting, input validation |
| Third-Party Management | Vendors and partners | Risk assessment, access monitoring |
How to leverage this framework with Microsoft 365 and Azure
This model only has value if it becomes a concrete audit tool. The most effective method is to go through each pillar and ask yourself two questions: does the risk scenario described match my reality, and is the associated design point actually in place in my organization?
A few quick verification tips on the Microsoft side:
- For authentication and authorization: check your conditional access policies in Microsoft Entra ID and actual RBAC usage on your Azure subscriptions.
- For vulnerability management and endpoint security: Microsoft Defender for Endpoint and Microsoft Defender for Cloud provide a posture score and prioritized recommendations.
- For encryption: Azure Key Vault centralizes secret management, but you still need to verify that applications actually use it rather than hardcoded keys.
- For audit and compliance: Compliance Manager from Microsoft Purview helps map your regulatory obligations against deployed technical controls.
None of these tools replace the underlying approach: map responsibilities, identify blind spots, and prioritize investments based on your organization's actual risk, not a generic checklist.
Key takeaways
- Modern cybersecurity is thought of in depth, not as a single layer: the twelve pillars reinforce each other, and neglecting one weakens the others.
- Authentication and authorization form the foundation: clearly distinguishing "who you are" from "what you can do" prevents costly design errors.
- Resilience (disaster recovery, incident response) is as important as prevention, and far more often neglected.
- Third-party management extends the security perimeter beyond your own tenant — a critical point in interconnected cloud architectures.
- This model primarily serves as an audit tool: review each pillar, compare it to your actual risks, and verify the effective presence of the associated technical measures.
