The shared responsibility model and defence in depth

On the morning of October 20, 2026, Ama Boateng opened the security team's shared mailbox and found a message from the accounts payable team at Harrow & Finch Home Supply. A supplier had phoned to ask why the company's bank details had changed. Nobody in finance had changed anything. Within an hour Ama and her manager, Sunil Rao, had traced the problem to a store manager's mailbox. The manager had entered her password on a convincing fake sign-in page the previous afternoon, and someone had used it to sign in from overseas, read her email and send three suppliers a forged notice asking them to update the company's payment details. No money had moved, because the supplier called first, but the incident became the reason Harrow & Finch put identity security at the front of Project Skylight.

Sunil, the IT security manager, has a habit his team knows well. Before anyone proposes a control, he asks two questions: "What does this protect, and from whom?" Ama, a security analyst who joined his team from the service desk two years ago, has started studying for the SC-900 exam, Microsoft Security, Compliance, and Identity Fundamentals, and plans to book it for February 2027. Sunil offered to turn the incident review into a weekly study session. This course follows those sessions through November and December 2026, as the team plans the identity work that Renata Kowal, the cloud lead, calls the front door of Skylight.

This course is the first half of the SC-900 path. It covers the concepts of security, compliance and identity, and the capabilities of Microsoft Entra, Microsoft's family of identity and access products. The second course, MSAZ-131, covers Microsoft's security solutions, such as Defender for Cloud, Microsoft Sentinel and Defender XDR, and its compliance solutions in Microsoft Purview. According to the SC-900 study guide on Microsoft Learn (skills measured as of October 21, 2026), the concepts domain is weighted 10–15 and the Entra domain 25–30, out of 100. The guide lists a passing score of 700; it does not state the number of questions or the exam length, so this course does not either.

Who secures what in the cloud?

When Harrow & Finch ran everything in its own server room at head office in Winnipeg, the answer to "who is responsible for security?" was simple: the company was. It owned the building, the locks on the server room door, the power, the network switches, the servers, the operating systems, the applications and the data. If a disk failed or a door was left open, it was the company's problem. Moving to the cloud changes that answer, but it does not remove the company's responsibility. Instead, the work is divided between the customer and the cloud provider. That division is called the shared responsibility model.

The model is easiest to picture as a stack of layers, from the physical data centre at the bottom to the data and the people who use it at the top. In a traditional on-premises setup, the customer is responsible for every layer. When a workload moves to a cloud service, the provider takes over the bottom layers, and how far up the stack the provider's responsibility reaches depends on the type of service.

With infrastructure as a service (IaaS), such as an Azure virtual machine, Microsoft is responsible for the physical data centres, the physical network and the physical hosts that run the virtual machines. The customer is responsible for the operating system inside the virtual machine, its updates, the applications installed on it, the network controls placed around it, and everything above. When Theo Marchand, the systems administrator, built the first StockLine test servers in October, patching Windows on those servers stayed his job.

With platform as a service (PaaS), such as Azure App Service or Azure SQL Database, Microsoft also manages the operating system and much of the platform software. The customer still configures the service, controls who can reach it, writes or deploys the application code and protects the data. The web team's trial of App Service for a copy of harrowfinch.com moved Windows patching off their list, but deciding who could publish code to the site did not move anywhere.

With software as a service (SaaS), such as Microsoft 365, the provider runs almost everything: the data centres, the servers, the application itself and its updates. The customer is left with the parts that only the customer can do: deciding who has accounts, how they sign in, what they can access, how data is shared and labelled, and which devices are allowed to connect. The October incident happened in Microsoft 365, a SaaS service, and it happened in exactly the area that always belongs to the customer: an account and its password.

What always stays with the customer

Three things are the customer's responsibility no matter which kind of service is used. The first is information and data: the customer decides what data is stored, how it is classified, who can see it and how long it is kept. The second is devices: the laptops, phones, tablets and store tills that connect to cloud services are the customer's to manage and protect. The third is accounts and identities: the customer creates the user accounts, decides how people prove who they are and grants their permissions. Microsoft provides the tools for all three, but it cannot decide for you who should read the payroll files or whether a store tablet should be allowed to open them.

Sunil wrote those three items on the whiteboard after the incident review and drew a circle around the last one. "The attacker didn't break Microsoft's data centre," he said. "They didn't break Exchange. They used a real password on a real account. Everything that went wrong happened in our part of the model." Ama added a note to her study list: the shared responsibility model is not a way of handing security to the provider; it is a way of knowing exactly which jobs are still yours.

The model also explains a common misunderstanding. Some people assume that because a SaaS provider is responsible for most layers, an organization using SaaS needs less security work. In practice the remaining work becomes more important, because identity and data are now the main things standing between an attacker and the organization's information. A cloud service is reachable from anywhere on the internet, so a stolen password can be used from anywhere too.

Defence in depth

Knowing who is responsible is half the picture. The other half is how to protect the layers that are yours. Defence in depth is the strategy of using several layers of protection so that if one layer fails, others still slow or stop an attack. The idea comes from physical security: a castle had a moat, walls, a gatehouse, guards and a keep, and an attacker had to get through all of them. In information security, no single control is perfect. Passwords are stolen, software has flaws, people click links and settings are misconfigured. Layers make it much less likely that one mistake leads to a serious breach.

Microsoft's training describes defence in depth with a set of layers, each protecting the ones inside it. The exact list varies between sources, but a common version has seven layers, from the outside in.

• Physical security controls access to buildings and hardware, such as locked data centres and badge readers. In Azure this is Microsoft's job; in the head office server room it is still Harrow & Finch's.
• Identity and access controls who can sign in and what they can do, through strong authentication, least privilege and monitoring of sign-ins.
• Perimeter protects the edge of the network from large-scale attacks, for example with distributed denial-of-service protection and firewalls.
• Network limits communication between resources, with segmentation and rules that allow only the traffic that is needed.
• Compute protects virtual machines and other compute resources, for example by keeping them patched and closing management ports to the internet.
• Application builds security into software, such as fixing vulnerabilities and storing secrets safely instead of in code.
• Data protects the information itself, for example with encryption, classification and access controls.

The layers are a way of organizing thinking, not a checklist to complete once. A strong network layer does not make a weak identity layer acceptable. The October incident showed this: Harrow & Finch had firewalls and antivirus, but the attacker did not need to get through either. They went straight to the identity layer, where a password alone was enough.

Confidentiality, integrity and availability

Security teams often describe what they are protecting with three goals, known as the CIA triad. Confidentiality means information is seen only by people who are allowed to see it; encryption and access controls support it. Integrity means information is not changed without permission, and changes can be detected; hashing, digital signatures and change logs support it. Availability means systems and data are there when authorized people need them; backups, redundancy and protection against denial-of-service attacks support it.

The forged supplier email was an attack on integrity and, nearly, on money. The attacker wanted suppliers to change trusted payment details. A ransomware attack, which encrypts data and demands payment, attacks availability. A leaked customer list is a failure of confidentiality. Asking which goal a threat attacks helps choose the right control: encryption does not help much against a ransomware attack, but tested offline backups do.

Sunil likes to make the layered idea concrete with a small calculation. If each layer stops an attack with some probability, an attacker has to get past every layer, so the chance of getting through all of them is much smaller than the chance of getting through any one. The numbers below are illustrative, and real layers are not fully independent, but the shape of the result holds.

layers = {
    "Email filtering": 0.70,       # illustrative chance each layer stops the attempt
    "User spots the fake page": 0.40,
    "Multifactor authentication": 0.95,
    "Sign-in risk policy": 0.60,
}
chance_through = 1.0
for name, stop in layers.items():
    chance_through *= (1 - stop)
    print(f"After {name:28s} chance attacker is still in: {chance_through:.4f}")
print()
print("Without MFA the last two layers are missing:")
print(round((1 - 0.70) * (1 - 0.40), 4))

After Email filtering              chance attacker is still in: 0.3000
After User spots the fake page     chance attacker is still in: 0.1800
After Multifactor authentication   chance attacker is still in: 0.0090
After Sign-in risk policy          chance attacker is still in: 0.0036

Without MFA the last two layers are missing:
0.18

With only email filtering and an alert user, roughly one attempt in six would still succeed in this example. With multifactor authentication and a risk policy added, the chance falls to a small fraction of one in a hundred. That is the argument Sunil took to Renata and to Dana Whitcombe, the chief financial officer: no single layer is perfect, but together they change the odds dramatically.

Applying the ideas at Harrow & Finch

By the end of the first session, Ama had turned the theory into a list for Project Skylight. For each workload, the team would record its service type and therefore which layers Microsoft handles; name an owner for the layers that stay with Harrow & Finch; and check that at least two independent controls protect each important asset. StockLine on virtual machines would need operating system patching, network rules, identity controls and data protection. The e-commerce site on App Service would need application security, identity controls and data protection, but not operating system patching. Microsoft 365 would need identity controls, device rules and data protection above all.

Renata added one more point. "The shared responsibility model is also written down," she said. "Microsoft publishes it, and the contracts and compliance reports say what Microsoft commits to. When an auditor asks how we know the data centre is secure, we don't guess; we use Microsoft's reports." Those reports, and the Service Trust Portal where they are published, are covered in MSAZ-131.