Zero trust architecture maturity: where are you and where to go next?

In 2024, over 70% of organisations either have already adopted zero trust to an extent or are planning to within the next 12 months.

Of those remaining, 17% plan to adopt zero trust in due course, while only a stubborn 5% have no plans to adopt whatsoever.

So, with most people at some stage of adoption, the question becomes, how far along are you?

Organisations range all along CISA’s Zero Trust Maturity Model (ZTMM), from teenage dabblings in MFA (multi-factor authentication) to the venerable adopters of AI-driven, dynamic policy. This piece is designed to help you place yourself on that model, explore some ideas for acceleration, and fill in the background details on zero trust architecture for those 5% who’ve stuck their heads in the sand.

We’ll be covering:

1. What is zero trust and why have organisations rushed to adopt it?
2. The principles and pillars of zero trust architecture
3. CISA’s Zero Trust Maturity Model and where you place 
4. Three ideas for accelerating your zero trust adoption 

Let’s get started.

What is zero trust architecture? (Skip this if you’re well aware)

To understand what zero trust architecture is, it’s useful to know the lineage.

From moat and castle to airport security: the moat and castle

Before the widespread adoption of cloud, most security was perimeter-based. This means using technologies like firewalls and IDSs to prevent malicious actors from penetrating the system and gaining access to resources.

This is often conceived of as a ‘castle-and-moat’ defence.

However, this form of cyber security was invalidated by the widespread adoption of cloud, BYOD (bring your own device) and IoT (internet of things).

The dark ages: an interim solution

Moving data to the cloud essentially brought resources outside traditional firewalls; while BYOD policies brought unsecured devices in.

In general, there was no longer a single perimeter behind which all resources sat.

A number of interim solutions, such as VPNs, SSO, and basic IAM, sought to extend perimeters and restrict access. However, this phase of cyber security was scattered and fragmented. These solutions weren’t unified under a single banner or philosophy.

Enter…

Zero trust architecture: the airport security approach

First coined in 2010, zero trust architecture was a response to the increased attack surface, dissolved perimeters and increasingly distributed networks that were fast becoming the norm.

While zero trust architecture does place emphasis on (and innovates) strong perimeters, the major paradigm shift is more inward-facing. Rather than barring all malicious actors from entry, zero trust accepts the inevitability of breaches and focuses on ensuring those inside the system are monitored and validated continuously.

This is sometimes imagined as the airport security model: a series of stringent borders at every checkpoint.

Zero trust architecture: principles and pillars

The core principles of zero trust were introduced by John Kindervag in 2010. Since then, some organisations have interpreted and tweaked, but the three core principles are more or less consensually known as:

Continuous verification

This means verifying each user, device and action, continuously. As you can imagine, this is a real departure from a perimeter-based security approach.

Least privilege access

Least privilege access is the idea of giving the fewest necessary permissions to any user on a task-by-task basis. This more granular approach to access keeps users within strict guidelines inside the system.

Assume breach

The third and guiding principle, assume breach, means what it says: do not design impenetrable systems; design systems which, once penetrated, give up nothing to malicious actors and challenge them at every turn.

The 5 pillars of zero trust architecture

Since its coinage, zero trust has gained widespread popularity. Many organisations have run with zero trust, spawning more than a few formal frameworks, pillars and codifications.

Today, we’ll be focussing on CISA’s five pillars. Other organisations’ tenets, pillars, principles et al are available, but these represent a broadly agreed upon and mature standard upon which to base any zero trust strategy.

1. Identity

In zero trust, user identity and access management are granular and contextual. No user is granted implicit trust. Trust is conditional on multiple factors such as time, location, and device health.

Further, users are continuously identified and monitored through granular access controls ensuring that access remains appropriate and secure throughout their session. At the most mature end of the scale, this is powered by AI and automation.

2. Devices

The zero trust security model does not assume devices are secure just because they’re connected to the network.

Using EDR (endpoint detection response) tools, practitioners continuously monitor both organisational, BYOD and IoT devices for health and compliance. If a device falls short of policy requirements, access will be restricted or revoked. Again, the more mature the zero trust implementation, the more automation.

3. Network

Zero trust network access does away with the idea of a single perimeter. Using micro-segmentation technologies like SD-WAN and VPNs, practitioners secure traffic at various points within the network, essentially turning your app into a series of gated rooms.

4. Applications and workloads 

In zero trust, applications also fall under scrutiny. To prevent compromised applications or workloads from moving laterally, RASP tools are used to detect and prevent unauthorised behaviour, such as an application accessing a secured database.

5. Data

In zero trust, sensitive data is treated with greater care. In contrast to previous security models in which a high-level user could download at will, more granular forms of user identity are enforced, with data access given on a least privilege basis.

In addition, as with all other pillars, a mature application of zero trust means constant monitoring and automated, dynamic responses to unusual behaviour.

Zero trust architecture maturity

Now we’ve covered the basics, we’ll be moving on to the main event. This next section assumes a little more intimate knowledge of zero trust and cyber security in general, and will hopefully allow you to think about your own organisation’s maturity.

To do this, we’ll briefly outline CISA’s maturity model, then move on to analyse what that looks like in each pillar.

What is CISA’s Zero Trust Maturity Model

CISA’s zero trust maturity model describes 4 stages of adoption:

Traditional

Organisations at this stage rely heavily on perimeter-based defences like firewalls and VPNs. Policies are static. Automation is minimal.

Initial

Some foundational zero trust practices (such as MFA) have been partially adopted. Other practices may be implemented in isolation.

Advanced

Many of the zero trust pillars are in place. The organisation has leaned into automation and implementation is centrally planned.

Optimal

The pillars of zero trust are all in place. Automation based on real-time analysis has been maximally applied across the organisation.

So, where are you?

1. The identity pillar

The traditional stage

At this level, identity is managed across fragmented systems without one central IAM tool. Authentication relies heavily on passwords, perhaps with some basic MFA. Identity risk is evaluated manually using static rules, and privileged accounts don’t receive any extra scrutiny.

You might be at this stage if:

• Your team frequently forgets or resets passwords for multiple disconnected systems
• High-privilege accounts are treated the same as standard ones
• Access reviews are none too frequent, perhaps being prompted by breaches

Initial stage

Now, identity management is partially centralised with some integration. MFA is more common, perhaps boosted by phishing-resistant options like FIDO2. Risk-based access policies are rudimentary, based on static attributes like IP address with some contextual factors.

You might be at this stage if:

• Employees consistently use MFA but it isn’t enforced across your environment; you may have some legacy systems accessible by password
• Access to sensitive apps from unmanaged devices or strange locations can occur undetected
• Centralised identity tools handle most, but not all, of your users

Advanced stage

Now nearing full maturity, identity systems are consolidated into a unified provider. Risk-based policies can now dynamically adjust users’ access based on contextual (not static) signals; device compliance, user behaviour, etc. Privileged accounts are now properly managed with tools like PIM (privileged identity management)

You might be at this stage if:

• Logins with unusual patterns prompt extra credential checks
• Your admin accounts require approval workflows for access to critical systems
• Sustained and potentially malicious behaviours (repeated failed logins) trigger automated alerts

Optimal stage

If you’re fully mature, identity is continuously validated using real-time behavioural analytics and dynamic rules. Continuous Access Evaluation (CAE) ensures permissions actually adapt during sessions. The key difference between this and the previous stage is that policies are now generated dynamically by observing patterns throughout the system.

You might be at this stage if:

• Access permissions shift mid-session
• Offboarding processes ensure terminated employees immediately lose access across all systems
• Automated systems proactively flag accounts for review

2. The devices pillar

Traditional stage

At this stage, devices lack centralised oversight, and security posture is something of a mystery. Access hinges on credentials alone, giving unmanaged or personal devices free rein. Patching is sporadic if done at all.

You might be at this stage if:

• Users regularly bring their own devices (BYOD) with no checks on software updates or antivirus protection
• Patch cycles rely on manual reminders
• Legacy systems and on-premises tools offer only basic visibility (e.g. a spreadsheet-based device inventory)

Initial stage

You’re now beginning to enforce device compliance. Limited tooling (e.g., MDM or basic cloud device management) requires devices meet certain criteria before accessing critical resources. Some automated patching and inventory tracking have been implemented.

You might be at this stage if:

• Your core set of organisational laptops is tracked using an MDM solution
• Patches are pushed on a schedule, but employees still defer them and there’s no formal process to name and shame
• BYOD rules exist, but monitoring is minimal

Advanced stage

At this stage, device compliance is continuously monitored and enforced for both corporate and BYOD. Automated processes handle patching, configuration, and vulnerability checks. Non-compliant devices face restricted access, guided by zero trust principles like “never trust, always verify.”

You might be at this stage if:

• You use tools like Cisco AnyConnect or Okta Device Trust to evaluate device health at login
• Automated patch management deploys updates across the business, and devices failing these compliance checks are promptly quarantined
• Detailed device inventories cover laptops, mobile devices, and IoT endpoints (depending on device capabilities in this last case), giving you a real-time bird’s-eye view of device security

Optimal stage

Devices are assessed dynamically throughout their lifecycle, integrating real-time threat intelligence and automated remediation. JIT (just-in-time) access policies ensure only compliant, contextually approved devices can perform sensitive actions – which is a more granular level of restriction as opposed to simple check-at-login policies. Remediation also leans into automation.

You might be at this stage if:

• High-risk devices are remediated and/or isolated without human intervention
• IoT endpoints are monitored and dynamically protected to the furthest possible extent
• AI-driven or advanced analytics tools (e.g., Microsoft Defender for Endpoint, CrowdStrike Falcon device posture checks) govern real-time risk decisions, instantly adapting device privileges to patterns within the system

3. The network pillar

Traditional stage

Organisations at this stage implement basic segmentation to isolate critical workloads, but connectivity remains static for the most part. Network rules are manually established, and threat response is reactive. Encryption for internal communications is likely limited or inconsistent.

You might be at this stage if:

• Your network segmentation separates by broad zones, for example partitioning guest WiFi
• Firewall rules are manually configured and rarely updated unless you’re responding to a recent incident
• Traffic encryption is nascent and mostly focused on externally-facing services

Initial stage

Now, segmentation is expanded, introducing basic traffic management features. Static network rules are applied at the application level, and encryption policies for internal traffic are firmly on the agenda. Monitoring tools provide at least some visibility into traffic patterns and potential threats.

You might be at this stage if:

• You use VLANs or similar to segment traffic between applications and departments
• Encryption policies use HTTPS or TLS for internal communications, though again, this might be patchy
• Network logs are collected but only reviewed during audits or in response to a major breach

Advanced stage

Now, network segmentation gets more granular with segmentation powered by SDN (software-defined networks). Traffic management uses some dynamic rules that adjust configurations based on risk, leveraging automated analysis and threat intelligence at a nascent level. Encryption is now consistently applied to internal and external traffic, with automated processes in control of certificates and keys.
You might be at this stage if:

• Micro-segmentation separates workloads, devices, and user groups based on business-criticality, with high-value assets placed in isolated trust zones
• Tools like Palo Alto’s Prisma Access or Cisco Secure Firewall dynamically adjust rules based on factors like unusual traffic patterns
• SSL/TLS certificates are rotated automatically

Optimal stage

At full maturity, network architecture evolves into distributed micro-segmentation, where ingress and egress perimeters adapt automatically. We’re now aiming to segment at the level of individual processes, data flows and containers, although this may be hard to realise fully. Traffic rules are continuously optimised through AI-driven tools, and encryption is applied dynamically based on the sensitivity of the data.

• AI-powered solutions like Microsoft Sentinel continuously refine network rules for both performance and security
• Real-time behavioural monitoring detects potential lateral movement and immediately isolates affected resources
• Segmentation is laser-focussed by business needs, i.e. granting access on a need-to-know basis, i.e. between a payment processing container and a billing database

4. The applications and workloads pillar

Traditional stage

Organisations at this level rely on static access controls and lack integration with IAM tools. Threat protection measures are minimal, and development processes lack structured security, relying on manual testing instead. Application-to-application communication uses insecure methods like hardcoded credentials.

You might be at this stage if:

• Users log into applications with standalone credentials, and security relies on passwords
• Security testing occurs late in development and is manual and inconsistent
• Applications are isolated on static infrastructure without safeguards for inter-application communication

Initial stage

Next, we begin to centralise application access management, incorporating contextual factors. Threat protection is applied to critical applications, while development pipelines experiment with basic automation. Application interactions adopt basic security measures, such as mutual TLS, to reduce exposure.

You might be at this stage if:

• MFA is introduced for mission-critical apps, while lower-priority apps rely on simpler methods
• Development processes integrate basic vulnerability scans but lack comprehensive automation
• Applications use basic security mechanisms for inter-application communication, such as static API keys or mutual TLS

Advanced stage

Access management becomes dynamic, leveraging behavioural data and device compliance. Threat protection covers a wider range of applications, including legacy systems. Automated tools handle vulnerability scanning and compliance checks during development. Advanced authentication, such as OAuth 2.0, protects applications, while RASP tools like Contrast Security monitor behaviour in real time.

You might be at this stage if:

• Access decisions adapt dynamically based on user actions, supported by tools like Zscaler
• Development pipelines employ tools like Snyk or Aqua Security for automated vulnerability checks
• Inter-app communication is now secured via API gateways and is consistently monitored

Optimal stage

At the optimal stage, applications and workloads are highly secure. Workloads become immutable, vastly reducing attack surface, and inter-app communication is even more protected with more granular control of API gateways. Access is assessed and adapted in real time. Automation is leveraged for security scanning and remediation and applied at scale.

You might be at this stage if:

• Continuous risk assessment governs application access, adapting policies mid-session
• Immutable workloads are deployed with tools like Terraform, ensuring changes require redeployment
• Anomalies, such as multi-stage attacks, are detected and mitigated by augmented RASP functionalities leveraging dynamism and AI

5. The data pillar 

Traditional stage

At zero maturity, you rely on manual processes for managing data inventory, access, categorisation, and encryption. Basic measures, such as isolated backups and selective encryption, are applied inconsistently without a comprehensive policy.

You might be at this stage if:

• Your data inventory relies on spreadsheets or other manual tracking
• Encryption is applied ad hoc, primarily to files explicitly marked as sensitive
• Backups are stored locally with no attention to redundancy or long-term accessibility

Initial stage

Now, you’re beginning to automate data inventory and classification for both structured and unstructured data. Sensitivity labels and encryption policies are deployed but may be applied inconsistently across data at rest and in transit. Data loss prevention (DLP) efforts may be limited to pilots or special cases.

You might be at this stage if:

• Sensitive information is tagged using initial tools like Microsoft Purview, but a good deal of data remains uncategorised
• Encryption policies are in place for data in transit, but data at rest is unprotected
• Data-sharing policies only restrict sensitive files

Advanced stage

Automation extends to enterprise-wide data categorisation and labelling. Consistent encryption policies now apply to both data at rest and in transit. Context-based access controls enforce least-privilege principles, and data loss prevention mechanisms are robust and proactive.

You might be at this stage if:

• You use tools like AWS Macie or Microsoft Purview to automatically classify sensitive data across the business
• Contextual factors like roles and location determine access
• DLP policies proactively prevent unauthorised data transfers and include remediation

Optimal stage

Enterprises at this level achieve comprehensive, real-time visibility and control data across its lifecycle. Encryption now extends to data in use, in addition to data at rest and in transit, supported by dynamic access controls like JIT and JEA (just enough access). AI-powered analytics continuously refine policies to mitigate evolving risks.

You might be at this stage if:

• Encryption policies dynamically secure active datasets using tools like Intel SGX
• Behavioural analytics identify anomalies in access patterns and trigger instant responses
• AI-driven DLP systems integrate with security tools like Splunk to prevent data exfiltration without the need for manual automation

So how did you fare?

Three ideas for accelerating your zero trust maturity

Whether your organisation is starting from a traditional baseline, accelerating initial adoption to the advanced stage, or making that final leap to full maturity, here are three strategies to get you where you’re going.

1. Pilot-led exploration – for those at the traditional or nascent initial stages

For those just starting out, a pilot scheme can be the best way to test the waters before full adoption. If you placed mostly in the traditional or initial stages, this may be the approach for you. Here’s how:

Establish a team

Banding together members of the business, security and engineering departments of your organisation, forge a small team responsible for conducting the pilot using clear KPIs.

Focus on quick wins

Choose a bite-sized project. For example, applying MFA to high-privilege user accounts. If there are known problem areas in your security posture, start there.

Iterate and expand

Feedback from this pilot will help you refine and upskill the team, readying them to move on to the next pilot.

2. Incremental/phased adoption

If you’re some way into zero trust adoption with a well-established team (perhaps one built up from a few successful pilots), a more structured approach is the way to go. This will benefit those placing confidently in the initial maturity stages with some placing in the advanced level. You can proceed by:

Conducting a gap analysis

Conduct a gap analysis on a pillar basis, identifying those areas which tend more toward initial maturity levels.

Move each pillar gradually to advanced

Organisations at this level are generally smaller with a leaner zero trust team or committee. The skills gained via moving your less advanced pillars to a more mature level will help you conquer the next phase – rather than trying to raise your security posture all at once.

Align with business priorities

At this stage, work undertaken is less experimental and will have a direct impact on the wider business. As you begin to move pillars to a comfortably advanced level, keep in communication with key stakeholders and allow this to dictate new directions.

3. Holistic alignment

Now, the team is well-established and the direction of travel is clear. You will now be focused on iterating automation and AI enhancement in a mostly mature zero trust environment.

Create a zero-trust committee

This is distinguished from the team in the pilot by seniority, resources and focus. Rather than a small team focused on delivery, this committee will be a change leader: delegating, leading training for employees and working with external suppliers.

Enhance vendor relationships

At this stage, you’ll be working closely with vendors. These may be consultants, third-party teams or enterprise support teams at zero trust solutions. One of your committee’s main tasks should be creating standard documentation and an internal structure to allow for seamless collaboration.

Conduct scenario-based testing

Test your automation using simulated attacks. When you’re nearing the optimal maturity stage, red team exercises and interoperability tests allow you to see how the complex layers of automated detection and response hold up in the case of an attack.

How we can help

As a cloud-native support provider, we help manage and secure cloud environments for everyone from scrappy start-ups to established enterprises.

So whether you’re starting at traditional, or looking to accelerate an existing adoption, we’re here to make it easier. Just get in touch, and let’s figure out how to get you where you need to be.