CyberCQR Case study · Identity and Zero Trust
Secure mobilisation at scale: from the office network to cloud identity
How tens of thousands of users at a large UK financial services organisation moved from an estate that was about 90% on-premises to secure remote working built on cloud identity, and how the same approach worked for an organisation of under 1,000 seats.
About this case study. Neil Brady led this programme in 2019 and 2020 as a contractor, before founding CyberCQR. The organisations are not named. Product names are given as they are today: Azure Active Directory is now Microsoft Entra ID, and Azure AD Application Proxy is now Microsoft Entra application proxy.
Summary
The point for boards. Remote working is not a network problem, it is an identity problem. Moving people off the office network safely meant deciding, for every sign-in and every application, who the user is, what device they are on and whether the request looks normal. Once identity carried that weight, the old perimeter, and much of the tooling that propped it up, could go.
The starting point
The organisation ran a traditional estate. About 90% of it was on-premises. Laptops and desktops were built and managed with Microsoft System Center Configuration Manager and dozens of other tools. Identity lived in on-premises Active Directory, with Active Directory Federation Services (ADFS) handling sign-in to cloud services. Remote users carried RSA hardware tokens and connected through a legacy virtual private network (VPN) that, once connected, gave access to a largely flat internal network.
That model works while most people sit in the office. For a workforce that is mostly remote it has three weaknesses:
- The VPN trusts the device once it is connected. On a flat network, one compromised laptop can reach far more than its user ever needs.
- Everything depends on things being shipped or built in the office. Device images, hardware tokens and certificates all needed physical handling or a connection to the internal network.
- The tooling multiplies. Each gap in the old model had its own product, and every product needed people to run it.
What changed
| Area | Before | After | Why it mattered |
|---|---|---|---|
| Device build and management | System Center Configuration Manager and dozens of other tools | Microsoft Intune with Windows Autopilot [1] | Devices could go from supplier to user and set themselves up over the internet, without passing through the office. |
| Directory and sign-in | On-premises Active Directory with ADFS | Microsoft Entra ID with password hash synchronisation [2] | Sign-in moved to the cloud service, removing the dependence on on-premises federation servers. |
| Multi-factor authentication (MFA) | RSA hardware tokens | Microsoft Authenticator app | No tokens to buy, ship, replace or recover when people leave. |
| Remote access | Legacy VPN onto a largely flat network | Application-centred Zero Trust access with Entra application proxy [3] | Users reached the specific applications they needed, after each sign-in was checked, not the whole network. |
| Certificates | Issued and renewed inside the network | Delivered to devices through Intune using the Network Device Enrollment Service (NDES) [4] | Devices received the certificates they needed wherever they were. |
| Access decisions | Largely decided by network location | Entra Conditional Access and ID Protection, including risky sign-in detection and location-based policies [5][6] | Each sign-in was judged on who, where, which device and how risky it looked. |
Table 1. The six moves. The controls listed under access decisions are the main ones; the programme used the wider set of Entra identity controls available at the time.
The perimeter moved from the network edge to every sign-in.
The design principles
Three ideas ran through every decision. They match what the National Cyber Security Centre (NCSC) now sets out in its Zero Trust architecture design principles [7].
- Identity is the control point. Every access decision starts with a strong, cloud-based identity, not with where the user is plugged in.
- Grant access to applications, not networks. Users see the applications they need and nothing else, so a compromised account or device reaches far less.
- Manage devices from the cloud. A device that can be built, checked and fixed over the internet does not need to come back to the office.
Scaling down: an organisation of under 1,000 seats
The same pattern was later applied to an organisation of under 1,000 seats. It delivered real cost savings and improvements in security compliance.
The approach suits mid-sized firms because much of it is often already paid for. Microsoft 365 Business Premium and E3 include Intune and Entra ID P1, which provides Conditional Access. Risk-based controls such as ID Protection need Entra ID P2, which comes with E5. The work is in designing and switching on what the licences already cover, then retiring what it replaces.
If we did it today
The architecture still holds. Some of the parts have moved on since 2020:
- Phishing-resistant MFA. We would move administrators first, then everyone, to passkeys or security keys rather than app approvals, which can be phished.
- Beyond web applications. Microsoft Entra Private Access extends application-level access to non-web applications, which used to keep a VPN alive for a few remaining systems.
- Cloud certificates. Microsoft Cloud PKI for Intune can now issue device certificates without running NDES and an on-premises certificate authority [8].
Lessons for a firm of 500 to 2,000 people
- Start with the licences you already own. Most firms pay for more identity and device management than they use.
- Move identity first. Cloud sign-in with strong MFA and Conditional Access is the foundation everything else depends on.
- Retire the VPN one application at a time, starting with the most used, and keep a list of what is left.
- Plan for the awkward cases early: certificates, older applications and shared devices take longest.
- Count what you retire. Tools, servers and contracts switched off are part of the business case, and part of the security case too.
Glossary
| Term | Meaning |
|---|---|
| Active Directory Federation Services (ADFS) | An on-premises Microsoft service that lets users sign in to other services with their corporate account. |
| Conditional Access | Entra ID rules that allow, block or challenge a sign-in based on the user, device, location and risk. |
| Entra application proxy | A Microsoft service that publishes internal applications to remote users through Entra ID sign-in, without a VPN. |
| Network Device Enrollment Service (NDES) | A Windows Server role that lets devices request certificates from an internal certificate authority, used by Intune to deliver them. |
| Password hash synchronisation | Copying a protected form of each password hash from on-premises Active Directory to Entra ID, so users sign in to cloud services directly. |
| Windows Autopilot | A Microsoft service that sets up new Windows devices over the internet for a specific user and organisation. |
| Zero Trust | A security approach that checks every access request on its merits instead of trusting anything inside the network. |
Table 2. Terms used on this page (alphabetical). Who the suppliers are: see Microsoft Entra on our references page.
Further reading
From CyberCQR
- The VPN Trap. Why legacy remote access is a board-level risk, and the alternatives that may already be paid for.
- Identity and Access Management: Top 10 Must-Do Actions. The identity controls to switch on first.
- Identity and Zero Trust. How we work with firms on this today.
References
- [1]Microsoft Learn, Overview of Windows Autopilot.
https://learn.microsoft.com/en-us/autopilot/overview - [2]Microsoft Learn, Implement password hash synchronization with Microsoft Entra Connect Sync.
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-password-hash-synchronization - [3]Microsoft Learn, Publish on-premises apps with Microsoft Entra application proxy.
https://learn.microsoft.com/en-us/entra/identity/app-proxy/overview-what-is-app-proxy - [4]Microsoft Learn, Configure infrastructure to support SCEP certificate profiles with Microsoft Intune.
https://learn.microsoft.com/en-us/intune/fundamentals/certificates/scep-infrastructure - [5]Microsoft Learn, What is Conditional Access?
https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview - [6]Microsoft Learn, What is Microsoft Entra ID Protection?
https://learn.microsoft.com/en-us/entra/id-protection/overview-identity-protection - [7]National Cyber Security Centre, Zero Trust architecture design principles.
https://www.ncsc.gov.uk/collection/zero-trust/architecture-design-principles - [8]Microsoft Learn, Microsoft Cloud PKI for Microsoft Intune.
https://learn.microsoft.com/en-us/intune/cloud-pki/
Security is the outcome, not a solution.
CyberCQR is a UK cyber security advisory practice. We help organisations move to identity-centred security using the Microsoft licences they already own, without vendor commissions or product resale.