Zero Trust Architecture: The new standard for Norwegian IT security

Zero Trust is a security model where no user, device, or network zone is trusted automatically — regardless of whether they are inside or outside the corporate network. The principle is simple: never trust, always verify. Every access request must be authenticated, authorised, and encrypted before access is granted.

In a world where employees work from home, cloud services replace on-premises servers, and cyberattacks grow increasingly sophisticated, building a wall around the corporate network is no longer sufficient. The traditional approach — "trust everything inside the firewall" — has itself become a security risk. Norway's National Security Authority (NSM) now recommends Zero Trust as a central part of Norwegian organisations' security strategies, and with NIS2 and the new Digital Security Act, requirements for access control, monitoring, and incident handling are stricter than ever. In this article, we explain what Zero Trust is, how to implement it step by step, and which tools make it practically achievable.

What is Zero Trust?

Zero Trust is a security model based on the principle that no user, device, or network zone should be trusted automatically — regardless of whether they are inside or outside the corporate network. Every access request must be authenticated, authorised, and encrypted before access is granted.

The core principles can be summarised in three points:

1. Verify explicitly: Always authenticate and authorise based on all available information — identity, device health, location, service, and data classification.
2. Use least privilege access: Limit user access with just-in-time (JIT) and just-enough-access (JEA) principles. Grant only the permissions needed, when they are needed.
3. Assume breach: Design systems as if the attacker is already inside. Segment access, encrypt all traffic, and use continuous monitoring to detect anomalies.

Traditional perimeter security vs. Zero Trust

To understand why Zero Trust is necessary, it is helpful to compare it with the traditional model:

Aspect	Traditional perimeter security	Zero Trust
Trust model	Trust everything inside the network	Never trust anything, always verify
Network focus	Firewall and VPN protect the boundary	Identity is the new perimeter
Access control	Broad network access after login	Granular, context-based access per resource
Lateral movement	Easy to move within the network	Micro-segmentation limits movement
Device control	Corporate-owned devices are trusted	All devices are continuously verified
Monitoring	Focus on the perimeter	Continuous monitoring of all traffic
Cloud compatibility	Poorly suited for hybrid/cloud	Designed for cloud and hybrid
Vulnerability	One compromised point grants broad access	Breaches are contained to individual resources

The five pillars of Zero Trust

A robust Zero Trust architecture is built on five pillars that together cover the entire attack surface:

1. Identity

Identity is the foundation of Zero Trust. Every user, service account, and machine identity must be verified with strong authentication before access is granted.

• Multi-factor authentication (MFA) for all users
• Passwordless authentication where possible (FIDO2, Windows Hello)
• Conditional access based on risk signals
• Privileged identity management with time-limited permissions

2. Devices

Devices accessing corporate resources must meet security requirements — regardless of whether they are corporate-owned or personal.

• Registration and management of all devices
• Health checks: update status, antivirus software, encryption
• Conditional access based on device compliance status
• Automatic isolation of devices that fail to meet requirements

3. Network

The network should no longer be a trust zone. All traffic must be encrypted and segmented.

• Micro-segmentation of the network
• Encryption of all traffic — including internal
• Network-based access control and traffic inspection
• Real-time monitoring of network patterns

4. Applications

Applications must be protected with proper access control and continuous monitoring.

• Single sign-on (SSO) and conditional access
• Shadow IT discovery and control
• API security and integrity verification
• Application-based segmentation

5. Data

Data is what attackers are ultimately after. Protecting data is the ultimate goal of Zero Trust.

• Data classification and labelling
• Encryption at rest and in transit
• Data loss prevention (DLP)
• Rights management and access logging

Zero Trust maturity model

Implementing Zero Trust is a gradual process. This maturity model helps you assess where your organisation stands:

Maturity level	Identity	Devices	Network	Applications	Data
Traditional	Username/password	No device control	Flat network structure	Direct access	No classification
Basic	MFA for admin users	Device registration	Network segmentation	SSO for cloud apps	Basic encryption
Advanced	MFA for all, conditional access	Compliance checks, MDM	Micro-segmentation	All apps via SSO, shadow IT control	Classification and DLP
Optimal	Passwordless, risk-based	Real-time health, automated response	Fully encrypted, AI monitoring	API security, CASB	Automatic labelling, rights management

Step-by-step implementation

Step 1: Secure identity (0–3 months)

Start with what delivers the greatest impact fastest — identity and access management:

• Enable MFA for all users, prioritising administrators and privileged accounts
• Implement conditional access with risk-based policies
• Introduce self-service password reset and passwordless methods
• Enable identity protection with automatic detection of risky sign-ins

Step 2: Register and secure devices (2–5 months)

• Register all devices that access corporate resources
• Define compliance policies for devices (encryption, updates, antivirus)
• Configure conditional access requiring compliant devices
• Implement automated responses for devices that fall out of compliance

Step 3: Segment the network (4–8 months)

• Map network traffic and identify communication patterns
• Implement micro-segmentation based on application dependencies
• Encrypt all internal traffic where possible
• Set up network monitoring and anomaly detection

Step 4: Protect applications and data (6–12 months)

• Migrate all applications to SSO with conditional access
• Implement data classification and sensitivity labelling
• Enable DLP policies for sensitive data
• Set up logging and monitoring across all pillars

Azure-based Zero Trust implementation

For organisations using Microsoft Azure and Microsoft 365, a complete ecosystem for Zero Trust is available:

Pillar	Azure tool	Function
Identity	Microsoft Entra ID (formerly Azure AD)	MFA, conditional access, identity protection
	Entra ID Privileged Identity Management	Time-limited and approval-based privileged access
Devices	Microsoft Intune	Device registration, compliance policies, app protection
	Microsoft Defender for Endpoint	Endpoint security and threat detection
Network	Azure Firewall Premium	Network filtering and threat protection
	Azure Private Link	Private connectivity to cloud services
Applications	Microsoft Defender for Cloud Apps	CASB, shadow IT discovery, app governance
	Azure Application Gateway with WAF	Web application protection
Data	Microsoft Purview Information Protection	Classification, labelling, and encryption
	Microsoft Purview Data Loss Prevention	DLP across email, files, and endpoints
Monitoring	Microsoft Sentinel	SIEM/SOAR for centralised security monitoring

Conditional access in practice

Conditional access in Microsoft Entra ID is the heart of an Azure-based Zero Trust architecture. Here is an example policy structure:

1. Baseline policy: Require MFA for all users on all applications
2. Device policy: Require a compliant device for access to sensitive applications
3. Location policy: Block access from countries where the organisation does not operate
4. Risk policy: Require password change on high sign-in risk
5. Admin policy: Require phishing-resistant MFA and a compliant device for all administrators

NSM recommendations for Norwegian organisations

Norway's National Security Authority (NSM) has laid the foundation for the Zero Trust approach in Norway through its basic principles for ICT security and related guidance:

• Principle of least privilege: Grant users and systems only the access that is strictly necessary
• Network segmentation: Divide the network so that compromise of one zone does not grant access to the rest
• Strong authentication: Use multi-factor authentication for all remote access solutions and privileged accounts
• Logging and monitoring: Log all access and monitor for anomalous activity
• Secure configuration: Harden all systems and services according to recognised standards

NSM's basic principles align closely with the Zero Trust model and provide a practical framework for Norwegian organisations looking to get started.

Connection to NIS2 and the Digital Security Act

Zero Trust architecture directly supports several NIS2 requirements that Norwegian businesses must meet:

• Access control and authentication (NIS2 requirements 9 and 10): The Zero Trust pillars for identity and devices meet the requirements for multi-factor authentication and access control
• Risk analysis and policies (NIS2 requirement 1): Zero Trust requires documented security policies and continuous risk assessment
• Incident handling (NIS2 requirement 2): Continuous monitoring and logging make it possible to detect and report incidents within the 24-hour deadline
• Supply chain security (NIS2 requirement 4): Zero Trust principles also apply to third-party access and supplier integrations

Common implementation mistakes

Many organisations make errors that undermine their Zero Trust implementation. Here are the most common:

1. Too broad a scope from the start: Trying to implement everything at once instead of taking it step by step. Start with identity and expand gradually.
2. Forgetting the user experience: Security measures that are too burdensome cause users to find workarounds. Balance security with usability.
3. Ignoring legacy systems: Legacy systems that do not support modern authentication must be handled with compensating controls.
4. Lack of leadership buy-in: Zero Trust is an organisational change, not just a technology project. Leadership must understand and support the strategy.
5. Insufficient monitoring: Implementing access controls without monitoring creates a false sense of security. Logging and analysis are as important as the controls themselves.
6. Underestimating training needs: Employees must understand why security measures are necessary and how to use new tools.

How we can help

At UNOS SOFTWARE AS, we help Norwegian organisations design, implement, and operate Zero Trust architectures tailored to their needs and maturity level:

• Cloud infrastructure with built-in Zero Trust — through our cloud and infrastructure service, we build secure Azure environments with conditional access, micro-segmentation, and continuous monitoring
• Strategic consulting and architecture design — our technical consulting service helps you map the current state, define a Zero Trust roadmap, and select the right tools
• Secure application development — we build software with Zero Trust principles integrated from the start — role-based access control, API security, and end-to-end encryption

Zero Trust is not a product you buy — it is a strategy you implement over time. With the right partner and a step-by-step approach, your organisation can achieve a security posture that meets both NSM recommendations and NIS2 requirements.

Is your organisation ready for Zero Trust? Get in touch for an informal conversation about how we can help you get started.

---

Sources and further reading

• National Security Authority (2025). "Basic Principles for ICT Security." nsm.no
• Microsoft (2025). "Zero Trust deployment guide with Microsoft." learn.microsoft.com
• NIST (2020). "SP 800-207: Zero Trust Architecture." nist.gov
• NSM (2025). "National Digital Risk Assessment 2025." nsm.no
• Forrester Research (2025). "The Zero Trust Security Framework." forrester.com
• CISA (2025). "Zero Trust Maturity Model." cisa.gov