Why modern cloud security needs a Trust Level Framework instead.
For years, privileged access strategies have revolved around a familiar concept:
Tier 0.
If you’ve worked with Active Directory, you’ll almost certainly be familiar with Microsoft’s tiered administration model.
- Protect the domain controllers.
- Protect Enterprise Admins.
- Protect the infrastructure that everything else depends on.
It was a simple and effective way of reducing administrative risk in traditional on-premises environments.
The problem is…
Many organisations no longer operate that way.
Today, the control plane has shifted.
Identity has become the new security boundary.
Microsoft Entra ID, Conditional Access, Privileged Identity Management, Authentication Strengths, SaaS applications and cloud management platforms now hold the keys to the kingdom.
A compromised Global Administrator in Microsoft Entra ID can often have a greater impact than a compromised Domain Administrator ever could.
Yet many privileged access strategies are still being designed around an infrastructure model created almost two decades ago.
I don’t think Tier 0 is wrong.
I simply think it was designed to solve a different problem.
From Infrastructure Trust to Identity Assurance
Rather than asking:
Which tier does this server belong to?
Modern organisations should be asking:
What level of assurance should this identity require?
Those are very different questions.
The first focuses on infrastructure.
The second focuses on risk.
As organisations continue to adopt cloud-native identity, Zero Trust and passwordless authentication, it becomes increasingly difficult to categorise privileged access using traditional infrastructure tiers alone.
Instead, I believe we should be thinking in terms of Trust Levels.
Introducing the Trust Level Framework
The Trust Level Framework shifts the focus away from servers and infrastructure, placing identity assurance at the centre of privileged access design.
Rather than grouping administrators by the systems they manage, the framework categorises identities based on the potential impact they could have if compromised.
The greater the potential impact…
…the greater the level of assurance required.
That assurance isn’t achieved through a single control.
It is the combination of multiple controls working together.
- Authentication strength
- Device trust
- Just-In-Time access
- Approval workflows
- Session duration
- Monitoring and auditing
- Least privilege
Together, these controls determine the appropriate Trust Level for an identity.
The Four Trust Levels
TL1 – Strategic Control
These identities control the control plane itself.
Examples include Global Administrators, Privileged Role Administrators, Conditional Access Administrators and Authentication Policy Administrators.
A compromise at this level could result in complete loss of control over the tenant.
Because of that, TL1 identities require the highest level of assurance.
Typical controls include:
- FIDO2 Security Keys
- High Assurance Privileged Workstations (PAWs)
- Peer approval
- Mandatory justification
- Short activation windows
- Continuous monitoring
TL2 – Service Administration
TL2 identities manage critical enterprise workloads such as Exchange Online, Microsoft Teams, SharePoint Online, Intune and Power Platform.
Whilst the impact of compromise is significant, these identities generally operate within a defined service boundary rather than controlling the tenant itself.
TL3 – Operational Administration
Operational administrators support users and perform routine administrative tasks.
Helpdesk teams, user administrators and service desk analysts typically fall into this category.
The emphasis shifts towards operational efficiency whilst maintaining appropriate security controls.
TL4 – Workforce
Standard users performing everyday business activities.
Although these identities typically require fewer privileged controls, they should still benefit from modern authentication, device compliance and Zero Trust protections.
Trust Drives Assurance
One of the biggest advantages of this approach is that security naturally scales with privilege.
Higher privilege doesn’t simply mean more permissions.
It means stronger authentication.
More trusted devices.
Greater oversight.
Shorter activation periods.
More accountability.
Rather than applying identical controls to every administrator, the framework aligns assurance with business risk.
Technology Agnostic by Design
Although the examples shown within the framework reference Microsoft technologies, the principles themselves are platform independent.
Whether an organisation uses Microsoft Entra ID, Okta, Google Workspace, AWS IAM, CyberArk or another identity platform, the same question still applies:
How much assurance is required before this identity should be trusted?
That makes the framework applicable far beyond Microsoft environments.
Where This Goes Next
This article introduces the core concepts behind the Trust Level Framework, but there is much more to explore.
Over the coming weeks I’ll be publishing additional articles covering topics including:
- Authentication Assurance
- Device Assurance
- Privileged Access Workstations
- Authentication Strengths
- More on Passkeys and FIDO2 for adminstration
- Just-In-Time Administration
- Approval Models
- Break Glass Accounts
- Continuous Monitoring
- Identity Governance
Each of these areas contributes to the overall level of assurance required for modern privileged access.
Final Thoughts
Tier 0 helped define secure administration for an on-premises world.
Cloud-first organisations require something different.
Modern privileged access should no longer be designed around where systems live.
It should be designed around the level of assurance required before an identity is trusted.
For me, that’s where the Trust Level Framework begins.
Comments
No comments yet — be the first to leave one below.