MikroTik Zero Trust Network Access (ZTNA) Implementation: A Complete Guide for Network Engineers

MikroTik RouterOS has the feature depth to implement genuine ZTNA principles. Most engineers never configure it that way. This guide changes that.

This article provides a hands-on, phase-by-phase framework for implementing ZTNA on MikroTik infrastructure. Every section includes real RouterOS configurations, architectural decisions, and practical trade-offs. The target audience is network engineers and systems administrators managing MikroTik-based enterprise, ISP, or MSP environments.

1. Understanding Zero Trust Principles in the Context of MikroTik RouterOS

↑ Back to Top

1.1 The Five Pillars of Zero Trust (NIST SP 800-207)

NIST Special Publication 800-207 defines Zero Trust Architecture around five core principles. Every configuration decision in this guide maps back to one or more of these pillars:

1. Identity Verification — Every user, device, and service must authenticate before receiving any network access.
2. Device Trust and Posture Assessment — The network must evaluate device health and compliance before granting access.
3. Least-Privilege Access — Each entity receives only the minimum access required to perform its function.
4. Micro-Segmentation — Flat networks are eliminated. Workloads are isolated into discrete security zones.
5. Continuous Monitoring and Analytics — Trust is never permanent. The network continuously verifies behavior and flags anomalies.

1.2 MikroTik Feature Mapping to ZTNA Principles

RouterOS provides specific features that map directly to each Zero Trust pillar:

1.3 Where MikroTik Falls Short — and How to Compensate

MikroTik is not a purpose-built ZTNA appliance. Acknowledge these gaps and plan compensating controls:

• No native endpoint posture assessment. Compensate with external NAC solutions (PacketFence, Portnox) or RADIUS-based health checks.
• No built-in identity-aware firewall. Compensate with RADIUS-driven dynamic firewall rules and address list assignments.
• Limited native SIEM integration. Compensate with syslog forwarding to Wazuh, Graylog, or the ELK stack.
• No centralized policy orchestration across multiple routers. Compensate with Ansible playbooks, the REST API (RouterOS 7.x), or commercial tools like Unimus.

MikroTik should function as one layer in a defense-in-depth strategy — not the only layer.

2. Designing a MikroTik Zero Trust Architecture

↑ Back to Top

2.1 Network Topology Design for Zero Trust

A Zero Trust architecture replaces the flat network with clearly defined security zones. Each zone enforces its own access policy. A reference architecture includes these zones:

• Corporate Users — employee workstations and laptops
• BYOD / Guest — untrusted personal devices
• IoT / OT — cameras, sensors, building management systems
• Servers / Data Center — application and database servers
• DMZ — public-facing services (web servers, mail relays)
• Management — network infrastructure management interfaces
• Quarantine — devices that fail authentication or posture checks
• Internet / WAN — untrusted external connectivity

In NIST terminology, MikroTik functions as the Policy Enforcement Point (PEP). It enforces access decisions at the packet level. The Policy Decision Point (PDP) — typically a RADIUS server like FreeRADIUS — decides whether to grant access and what policy to apply. A Policy Engine (PE) — such as Ansible, a custom API integration, or centralized management — pushes and maintains consistent policies across all MikroTik devices.

2.2 Defining Trust Zones and Security Boundaries

Every zone maps to a VLAN, a subnet, and a dedicated firewall chain. Apply these rules:

• Each zone receives its own VLAN ID and IP subnet.
• All inter-zone traffic passes through the MikroTik router’s firewall (no direct L2 bridging across zones).
• The default policy between all zones is deny-all.
• Each permitted flow requires an explicit firewall rule with documented business justification.
• Intra-zone traffic is restricted where possible (port isolation, bridge firewall rules).

Example zone taxonomy:

2.3 Identity-Centric Access Model

Traditional access control uses static IP-based ACLs. Zero Trust replaces this with identity-driven policies:

1. A user or device connects to the network.
2. The device authenticates via 802.1X, VPN certificate, or captive portal.
3. RADIUS evaluates the identity and returns attributes: VLAN assignment, address list membership, bandwidth limits, session timeout.
4. MikroTik applies these attributes dynamically — placing the user into the correct zone with the correct policy.
5. The session has a finite lifetime. Re-authentication is required periodically.

Machine identities (servers, infrastructure devices, service accounts) authenticate using certificates and pre-shared keys instead of usernames and passwords.

3. Phase 1 — MikroTik Network Micro-Segmentation Configuration

↑ Back to Top

Micro-segmentation is the foundation of Zero Trust. Without segmentation, every other control is weakened. Start here.

3.1 VLAN Architecture and Implementation

MikroTik CRS3xx and CCR devices support hardware-offloaded VLAN filtering through the bridge VLAN filtering feature. This is the recommended approach for RouterOS 7.x.

Step 1: Create the bridge and enable VLAN filtering.

/interface bridge
add name=bridge1 vlan-filtering=yes pvid=1 frame-types=admit-only-vlan-tagged

# Note: Enable vlan-filtering ONLY after completing your VLAN configuration.
# Enabling it prematurely can lock you out. Configure first, enable last.

Step 2: Add ports to the bridge.

/interface bridge port
add bridge=bridge1 interface=ether2 pvid=20 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether3 pvid=20 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether4 pvid=30 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether5 pvid=40 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether6 pvid=50 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged  comment="Trunk to core"

Step 3: Define VLAN memberships.

/interface bridge vlan
add bridge=bridge1 vlan-ids=10 tagged=bridge1,sfp-sfpplus1 comment="Management"
add bridge=bridge1 vlan-ids=20 tagged=sfp-sfpplus1 untagged=ether2,ether3 comment="Corporate Users"
add bridge=bridge1 vlan-ids=30 tagged=sfp-sfpplus1 untagged=ether4 comment="Servers"
add bridge=bridge1 vlan-ids=40 tagged=sfp-sfpplus1 untagged=ether5 comment="IoT"
add bridge=bridge1 vlan-ids=50 tagged=sfp-sfpplus1 untagged=ether6 comment="Guest"
add bridge=bridge1 vlan-ids=99 tagged=bridge1,sfp-sfpplus1 comment="Quarantine"

Step 4: Create VLAN interfaces and assign IP addresses.

/interface vlan
add interface=bridge1 vlan-id=10 name=vlan10-mgmt
add interface=bridge1 vlan-id=20 name=vlan20-users
add interface=bridge1 vlan-id=30 name=vlan30-servers
add interface=bridge1 vlan-id=40 name=vlan40-iot
add interface=bridge1 vlan-id=50 name=vlan50-guest
add interface=bridge1 vlan-id=99 name=vlan99-quarantine

/ip address
add address=10.0.10.1/24 interface=vlan10-mgmt
add address=10.0.20.1/24 interface=vlan20-users
add address=10.0.30.1/24 interface=vlan30-servers
add address=10.0.40.1/24 interface=vlan40-iot
add address=10.0.50.1/24 interface=vlan50-guest
add address=10.0.99.1/24 interface=vlan99-quarantine

3.2 VRF for Workload Isolation

VLANs segment at Layer 2. VRF (Virtual Routing and Forwarding) segments at Layer 3 by creating completely separate routing tables. Use VRF when you need to ensure that two zones cannot route to each other under any circumstance — even if a firewall rule is misconfigured.

Use case: Isolating IoT devices into a routing domain that has no path to corporate servers.

# RouterOS 7.x VRF configuration
/ip vrf
add name=vrf-iot interfaces=vlan40-iot
add name=vrf-guest interfaces=vlan50-guest

# Default routes per VRF (internet-only access)
/ip route
add dst-address=0.0.0.0/0 gateway=198.51.100.1 routing-table=vrf-iot
add dst-address=0.0.0.0/0 gateway=198.51.100.1 routing-table=vrf-guest

# NAT for VRF traffic
/ip firewall nat
add chain=srcnat src-address=10.0.40.0/24 out-interface=ether1 action=masquerade comment="NAT IoT VRF"
add chain=srcnat src-address=10.0.50.0/24 out-interface=ether1 action=masquerade comment="NAT Guest VRF"

If specific controlled communication is needed between VRFs (e.g., IoT management from the management VLAN), use route leaking with strict firewall rules.

3.3 Firewall Rule Chains for Zero Trust Segmentation

This is the core enforcement mechanism. Create custom firewall chains for each zone-to-zone traffic flow. The default action is drop.

Step 1: Create interface lists for each zone.

/interface list
add name=ZONE-USERS
add name=ZONE-SERVERS
add name=ZONE-IOT
add name=ZONE-GUEST
add name=ZONE-MGMT
add name=ZONE-WAN

/interface list member
add interface=vlan20-users list=ZONE-USERS
add interface=vlan30-servers list=ZONE-SERVERS
add interface=vlan40-iot list=ZONE-IOT
add interface=vlan50-guest list=ZONE-GUEST
add interface=vlan10-mgmt list=ZONE-MGMT
add interface=ether1 list=ZONE-WAN

Step 2: Build the forward chain with zone-based jump rules.

/ip firewall filter

# --- Global forward rules ---
add chain=forward action=fasttrack-connection connection-state=established,related hw-offload=yes comment="FastTrack established"
add chain=forward action=accept connection-state=established,related comment="Accept established/related"
add chain=forward action=drop connection-state=invalid comment="Drop invalid"

# --- Jump to zone-specific chains ---
add chain=forward action=jump jump-target=USERS-TO-SERVERS in-interface-list=ZONE-USERS out-interface-list=ZONE-SERVERS
add chain=forward action=jump jump-target=USERS-TO-WAN in-interface-list=ZONE-USERS out-interface-list=ZONE-WAN
add chain=forward action=jump jump-target=IOT-TO-WAN in-interface-list=ZONE-IOT out-interface-list=ZONE-WAN
add chain=forward action=jump jump-target=GUEST-TO-WAN in-interface-list=ZONE-GUEST out-interface-list=ZONE-WAN
add chain=forward action=jump jump-target=SERVERS-TO-WAN in-interface-list=ZONE-SERVERS out-interface-list=ZONE-WAN

# --- Default deny all inter-zone traffic ---
add chain=forward action=log log-prefix="FWD-DENY:" comment="Log denied inter-zone"
add chain=forward action=drop comment="Default deny forward"

Step 3: Define zone-specific chain rules (least privilege).

# --- Users to Servers: explicit allows only ---
add chain=USERS-TO-SERVERS action=accept dst-address=10.0.30.10 protocol=tcp dst-port=443 comment="Allow HTTPS to app server"
add chain=USERS-TO-SERVERS action=accept dst-address=10.0.30.11 protocol=tcp dst-port=445 comment="Allow SMB to file server"
add chain=USERS-TO-SERVERS action=accept dst-address=10.0.30.12 protocol=tcp dst-port=3389 comment="Allow RDP to terminal server"
add chain=USERS-TO-SERVERS action=log log-prefix="USR-SRV-DENY:" comment="Log denied user-to-server"
add chain=USERS-TO-SERVERS action=drop comment="Deny all other user-to-server"

# --- Users to WAN: allow standard internet ---
add chain=USERS-TO-WAN action=accept protocol=tcp dst-port=80,443 comment="Allow HTTP/HTTPS"
add chain=USERS-TO-WAN action=accept protocol=udp dst-port=53 comment="Allow DNS"
add chain=USERS-TO-WAN action=accept protocol=tcp dst-port=53 comment="Allow DNS TCP"
add chain=USERS-TO-WAN action=drop comment="Deny all other user-to-WAN"

# --- IoT to WAN: restricted internet access ---
add chain=IOT-TO-WAN action=accept protocol=tcp dst-port=443 comment="Allow HTTPS only"
add chain=IOT-TO-WAN action=accept protocol=udp dst-port=123 comment="Allow NTP"
add chain=IOT-TO-WAN action=drop comment="Deny all other IoT-to-WAN"

# --- Guest to WAN: internet only, nothing else ---
add chain=GUEST-TO-WAN action=accept protocol=tcp dst-port=80,443 comment="Allow HTTP/HTTPS"
add chain=GUEST-TO-WAN action=accept protocol=udp dst-port=53 comment="Allow DNS"
add chain=GUEST-TO-WAN action=drop comment="Deny all other guest-to-WAN"

3.4 Layer 2 Hardening

Segmentation at Layer 3 is insufficient if Layer 2 attacks (ARP spoofing, DHCP exhaustion, MAC flooding) can bypass your controls. Harden the bridge:

• Enable DHCP snooping to prevent rogue DHCP servers.
• Enable ARP inspection (requires DHCP snooping) to prevent ARP spoofing attacks.
• Disable unused switch ports — an open port is an invitation.
• Limit MAC addresses per port to prevent MAC flooding.
• Enable storm control to prevent broadcast/multicast storms.
• Enable loop protection (RSTP + loop-protect on edge ports).

# DHCP Snooping
/interface bridge
set bridge1 dhcp-snooping=yes

/interface bridge port
set [find interface=sfp-sfpplus1] trusted=yes  comment="Trunk to core - trusted DHCP"
# All access ports remain untrusted (default)

# Disable unused ports
/interface ethernet
set ether7 disabled=yes comment="Unused - disabled"
set ether8 disabled=yes comment="Unused - disabled"

# Storm control on access ports
/interface ethernet
set ether2 storm-rate=500
set ether3 storm-rate=500

# Loop protection on edge ports
/interface bridge port
set [find interface=ether2] edge=yes point-to-point=no
set [find interface=ether3] edge=yes point-to-point=no

4. Phase 2 — Identity and Authentication

↑ Back to Top

Segmentation limits the blast radius. Authentication ensures only verified entities enter each zone. This is the “always verify” half of Zero Trust.

4.1 802.1X Port-Based Network Access Control

802.1X (Dot1X) authenticates devices at the switch port before granting network access. RouterOS 7.x supports Dot1X server functionality on bridge ports.

Architecture:

1. Client device (supplicant) connects to a MikroTik switch port.
2. MikroTik (authenticator) sends an EAP challenge.
3. Client responds with credentials (certificate or username/password).
4. MikroTik forwards the authentication request to FreeRADIUS (authentication server).
5. FreeRADIUS validates the identity and returns: Accept/Reject + VLAN assignment + other attributes.
6. MikroTik places the port into the assigned VLAN.

MikroTik Dot1X server configuration:

# Configure RADIUS client
/radius
add address=10.0.10.50 secret="YourRADIUSsecret!" service=dot1x timeout=3s

# Enable Dot1X on access ports
/interface dot1x server
add interface=ether2 auth-types=eap-tls accounting=yes interim-update=5m \
    reject-vlan-id=99 comment="Corporate port - 802.1X"
add interface=ether3 auth-types=eap-tls accounting=yes interim-update=5m \
    reject-vlan-id=99 comment="Corporate port - 802.1X"

Key parameters:

• auth-types=eap-tls — Use certificate-based authentication for strongest security.
• reject-vlan-id=99 — Failed authentications land in the quarantine VLAN.
• accounting=yes — Send RADIUS accounting records for audit trails.
• interim-update=5m — Send periodic updates to RADIUS during the session.

FreeRADIUS configuration for dynamic VLAN assignment (users file excerpt):

# /etc/freeradius/3.0/users

# Corporate user - assigned to VLAN 20
bob    Cleartext-Password := "disabled"
       Tunnel-Type = VLAN,
       Tunnel-Medium-Type = IEEE-802,
       Tunnel-Private-Group-ID = "20",
       Session-Timeout = 28800,
       Mikrotik-Rate-Limit = "10M/10M"

# IoT device via MAC Authentication Bypass (MAB)
00-1A-2B-3C-4D-5E Cleartext-Password := "00-1A-2B-3C-4D-5E"
       Tunnel-Type = VLAN,
       Tunnel-Medium-Type = IEEE-802,
       Tunnel-Private-Group-ID = "40",
       Session-Timeout = 86400

MAC Authentication Bypass (MAB) handles devices that cannot perform 802.1X (printers, IP cameras, legacy equipment). The device’s MAC address acts as its credential. This is weaker than certificate-based authentication, so MAB devices should always land in a restricted zone.

4.2 Certificate-Based Authentication for VPN and Management

Passwords are weak. Certificates are strong. For Zero Trust, every VPN and management connection should authenticate using X.509 certificates.

Step 1: Create a Certificate Authority on MikroTik.

# Create Root CA
/certificate
add name=ca-root common-name="MikroTik-ZTNA-CA" key-size=4096 days-valid=3650 \
    key-usage=key-cert-sign,crl-sign
sign ca-root ca-crl-host=10.0.10.1

# Create VPN Server Certificate
add name=vpn-server common-name="vpn.example.com" key-size=2048 days-valid=730 \
    key-usage=digital-signature,key-encipherment,tls-server \
    subject-alt-name=DNS:vpn.example.com,IP:203.0.113.1
sign vpn-server ca=ca-root

# Create Client Certificate
add name=client-bob common-name="bob@example.com" key-size=2048 days-valid=365 \
    key-usage=digital-signature,key-encipherment,tls-client
sign client-bob ca=ca-root

# Export client certificate (PKCS12) for distribution
export-certificate client-bob type=pkcs12 export-passphrase="SecureExportPass!"

Step 2: Configure certificate-based IKEv2 VPN (covered in detail in Phase 3).

Step 3: Enforce certificate authentication for management access.

# Require certificate for API-SSL
/ip service
set api-ssl certificate=vpn-server tls-version=only-1.2 address=10.0.10.0/24

# SSH key-based authentication (disable password auth)
/user ssh-keys import public-key-file=admin-key.pub user=admin

/ip ssh
set strong-crypto=yes always-allow-password-login=no

Certificate lifecycle management best practices:

• Set client certificates to expire every 365 days. Force annual renewal.
• Maintain a Certificate Revocation List (CRL). Revoke compromised certificates immediately.
• Store the CA private key securely. For production environments, use an offline CA or a dedicated tool like step-ca or OpenSSL instead of the MikroTik built-in CA.
• Automate certificate provisioning through SCEP or your organization’s PKI tooling.

4.3 RADIUS-Driven Dynamic Firewall Policies

This is where MikroTik gets closest to an identity-aware firewall. When a user authenticates (via VPN, Dot1X, or Hotspot), RADIUS returns MikroTik-specific attributes that dynamically apply firewall policies.

How it works:

1. User authenticates via VPN or 802.1X.
2. RADIUS returns Vendor-Specific Attributes (VSAs) for MikroTik.
3. RouterOS reads these attributes and applies them to the session.

Key MikroTik RADIUS attributes:

FreeRADIUS configuration example — dynamic address list assignment:

# FreeRADIUS users file
engineering-user  Cleartext-Password := "disabled"  # Using EAP-TLS, password is not used
    Mikrotik-Address-List = "acl-engineering",
    Framed-IP-Address = 10.0.20.101,
    Session-Timeout = 28800,
    Mikrotik-Rate-Limit = "50M/50M"

contractor-user   Cleartext-Password := "disabled"
    Mikrotik-Address-List = "acl-contractors",
    Session-Timeout = 14400,
    Mikrotik-Rate-Limit = "10M/10M"

MikroTik firewall rules referencing these dynamic address lists:

/ip firewall filter
add chain=forward src-address-list=acl-engineering dst-address=10.0.30.0/24 action=accept \
    comment="Engineering: full server access"
add chain=forward src-address-list=acl-contractors dst-address=10.0.30.10 protocol=tcp \
    dst-port=443 action=accept comment="Contractors: HTTPS to app server only"
add chain=forward src-address-list=acl-contractors action=drop \
    comment="Contractors: deny everything else"

The result: a user’s identity directly determines their firewall policy. When the session ends (timeout or disconnect), the address list entry is removed automatically. No persistent access.

4.4 Multi-Factor Authentication (MFA) Integration

Certificates provide strong single-factor authentication (something you have). For higher security, add MFA. MikroTik does not support MFA natively, but you can integrate it through the RADIUS layer.

Option 1: RADIUS + Duo Security Proxy (recommended for VPN authentication)

• Deploy the Duo Authentication Proxy on a server in your management VLAN.
• Configure MikroTik’s RADIUS client to point to the Duo proxy.
• The Duo proxy chains to your primary RADIUS/LDAP server for credential validation, then triggers a Duo push notification.
• The user approves the push → Duo proxy returns RADIUS Accept → MikroTik grants VPN access.

# MikroTik RADIUS client pointing to Duo proxy
/radius
add address=10.0.10.51 secret="DuoProxySecret!" service=ppp timeout=30s \
    comment="Duo MFA Proxy"

Option 2: Hotspot with external OAuth/SAML Identity Provider

• Use MikroTik Hotspot with a WISPr redirect to Keycloak, Azure AD, or Okta.
• The IdP handles MFA (TOTP, push, FIDO2).
• On successful authentication, the IdP redirects back and RADIUS authorizes the session.
• Best suited for BYOD/Guest access with browser-based authentication.

Option 3: RouterOS API + Custom TOTP Verification (advanced)

• Use a RouterOS script that queries an external API to verify a TOTP code submitted by the user.
• Complex to implement and maintain. Use only if no other option is available.

5. Phase 3 — Secure Remote Access: MikroTik VPN as a ZTNA Gateway

↑ Back to Top

5.1 ZTNA vs. Traditional VPN

A traditional VPN authenticates the user once, then grants full network access. This violates least-privilege and creates a large attack surface if the VPN credential is compromised.

A ZTNA VPN:

• Authenticates the user with strong credentials (certificate + MFA).
• Assigns the user to a specific zone with specific permissions.
• Grants access only to authorized applications — not the entire network.
• Enforces session timeouts and requires re-authentication.
• Logs all access for audit.

MikroTik can function as a ZTNA gateway by combining VPN authentication with per-user firewall policies driven by RADIUS.

5.2 IKEv2/IPsec VPN with Per-User Policies

IKEv2 is the preferred VPN protocol for ZTNA on MikroTik. It supports certificate-based authentication, has native client support on Windows, macOS, iOS, and Android, and handles network roaming via MOBIKE.

# IKEv2 IPsec configuration with certificate authentication

# Step 1: IP Pool for VPN clients
/ip pool
add name=pool-vpn-ztna ranges=10.0.100.2-10.0.100.254

# Step 2: IPsec Mode Config (pushes IP, DNS, and split routes to clients)
/ip ipsec mode-config
add address-pool=pool-vpn-ztna address-prefix-length=32 \
    name=ike2-ztna-cfg split-include=10.0.30.0/24 \
    system-dns=no static-dns=10.0.30.5 \
    comment="ZTNA: only push routes to authorized server subnet"

# Step 3: IPsec Profile
/ip ipsec profile
add name=ike2-ztna-profile hash-algorithm=sha256 enc-algorithm=aes-256 \
    dh-group=modp2048,ecp256 lifetime=8h

# Step 4: IPsec Proposal
/ip ipsec proposal
add name=ike2-ztna-proposal auth-algorithms=sha256 enc-algorithms=aes-256-cbc \
    pfs-group=ecp256 lifetime=1h

# Step 5: IPsec Peer
/ip ipsec peer
add name=ike2-ztna-peer exchange-mode=ike2 passive=yes \
    profile=ike2-ztna-profile send-initial-contact=yes

# Step 6: IPsec Identity (certificate-based)
/ip ipsec identity
add peer=ike2-ztna-peer auth-method=digital-signature \
    certificate=vpn-server remote-certificate=ca-root \
    match-by=certificate generate-policy=port-strict \
    mode-config=ike2-ztna-cfg policy-template-group=ike2-ztna

# Step 7: IPsec Policy Template
/ip ipsec policy group
add name=ike2-ztna

/ip ipsec policy
add group=ike2-ztna template=yes dst-address=10.0.30.0/24 \
    src-address=10.0.100.0/24 proposal=ike2-ztna-proposal

Critical ZTNA element: split-include=10.0.30.0/24

This pushes routes ONLY for the server subnet to the VPN client. The client does not receive a default route through the VPN. Users can reach only the specific resources they are authorized to access.

For per-user split tunneling based on role, use RADIUS to return different mode-config settings or apply firewall rules dynamically based on the user’s address list membership (as described in Section 4.3).

5.3 WireGuard VPN with Zero Trust Policies (RouterOS 7.x)

WireGuard’s cryptokey routing model is a natural fit for Zero Trust: each peer is identified by its public key and receives access only to the addresses defined in its allowed-address setting.

# WireGuard Interface
/interface wireguard
add listen-port=51820 mtu=1420 name=wg-ztna

# Peer: Engineering user — access to server subnet only
/interface wireguard peers
add allowed-address=10.0.200.2/32,10.0.30.0/24 \
    interface=wg-ztna \
    public-key="PeerPublicKeyBase64EncodedHere=" \
    endpoint-port=0 \
    persistent-keepalive=25s \
    comment="bob@engineering - server access"

# Peer: Contractor — access to single application server on port 443 only
/interface wireguard peers
add allowed-address=10.0.200.3/32 \
    interface=wg-ztna \
    public-key="ContractorPublicKeyBase64Here=" \
    endpoint-port=0 \
    persistent-keepalive=25s \
    comment="contractor-jane - app server 443 only"

# Assign IP to WireGuard interface
/ip address
add address=10.0.200.1/24 interface=wg-ztna

# Firewall: per-peer application-level control
/ip firewall filter
add chain=forward src-address=10.0.200.2 dst-address=10.0.30.0/24 action=accept \
    comment="WG: bob - full server access"
add chain=forward src-address=10.0.200.3 dst-address=10.0.30.10 protocol=tcp \
    dst-port=443 action=accept comment="WG: jane - app server HTTPS only"
add chain=forward src-address=10.0.200.0/24 action=drop \
    comment="WG: deny all other VPN traffic"

WireGuard does not have built-in RADIUS integration on MikroTik. Peer provisioning must be handled manually or automated via the RouterOS REST API and scripting.

5.4 Application-Level Access Control via Firewall

After VPN authentication, the firewall enforces application-level access. These rules restrict VPN users to specific IP:port combinations.

/ip firewall filter

# Time-based rule: Contractor access only during business hours (Mon-Fri 08:00-18:00)
add chain=forward src-address-list=acl-contractors dst-address=10.0.30.10 \
    protocol=tcp dst-port=443 action=accept \
    time=08:00:00-18:00:00,mon,tue,wed,thu,fri \
    comment="Contractors: HTTPS to app server, business hours only"

add chain=forward src-address-list=acl-contractors action=drop \
    comment="Contractors: deny all outside business hours"

# Protocol restriction: allow HTTPS, deny SSH for specific user group
add chain=forward src-address-list=acl-helpdesk dst-address=10.0.30.0/24 \
    protocol=tcp dst-port=443 action=accept comment="Helpdesk: HTTPS to servers"
add chain=forward src-address-list=acl-helpdesk dst-address=10.0.30.0/24 \
    protocol=tcp dst-port=22 action=drop comment="Helpdesk: deny SSH to servers"

6. Phase 4 — Securing the Management Plane

↑ Back to Top

The management plane is the most critical attack surface on any MikroTik device. A compromised router is a compromised network. Zero Trust applies to the router itself.

6.1 MikroTik Device Hardening

# Disable all unnecessary services
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set api disabled=yes
set api-ssl disabled=yes   # Enable only if API is required, with certificate + IP restriction
set www-ssl disabled=yes   # Enable only if WebFig is required
set ssh port=2222 address=10.0.10.0/24
set winbox port=18291 address=10.0.10.0/24

# Disable bandwidth test server
/tool bandwidth-server
set enabled=no

# Disable MAC server access on all interfaces
/tool mac-server
set allowed-interface-list=none

/tool mac-server mac-winbox
set allowed-interface-list=none

/tool mac-server ping
set enabled=no

# Disable neighbor discovery on non-management interfaces
/ip neighbor discovery-settings
set discover-interface-list=ZONE-MGMT

# Disable DNS cache if not acting as DNS server
/ip dns
set allow-remote-requests=no

# Disable UPnP
/ip upnp
set enabled=no

# Disable IP Cloud (unless required)
/ip cloud
set ddns-enabled=no update-time=no

6.2 Input Chain Firewall (Protecting the Router Itself)

/ip firewall filter

# --- INPUT chain: protect the router ---
add chain=input action=accept connection-state=established,related comment="Accept established/related"
add chain=input action=drop connection-state=invalid comment="Drop invalid"

# Management access from management VLAN only
add chain=input action=accept src-address=10.0.10.0/24 protocol=tcp dst-port=2222 \
    comment="SSH from management VLAN"
add chain=input action=accept src-address=10.0.10.0/24 protocol=tcp dst-port=18291 \
    comment="WinBox from management VLAN"

# DHCP server on internal interfaces
add chain=input action=accept protocol=udp dst-port=67 in-interface-list=!ZONE-WAN \
    comment="DHCP server"

# DNS (only if router serves DNS)
add chain=input action=accept protocol=udp dst-port=53 src-address=10.0.0.0/16 \
    comment="DNS from internal"
add chain=input action=accept protocol=tcp dst-port=53 src-address=10.0.0.0/16 \
    comment="DNS TCP from internal"

# IKEv2 VPN from WAN
add chain=input action=accept protocol=udp dst-port=500,4500 in-interface-list=ZONE-WAN \
    comment="IKEv2 VPN"

# WireGuard from WAN
add chain=input action=accept protocol=udp dst-port=51820 in-interface-list=ZONE-WAN \
    comment="WireGuard VPN"

# ICMP rate-limited
add chain=input action=accept protocol=icmp limit=10,5:packet comment="ICMP rate-limited"

# Drop everything else
add chain=input action=log log-prefix="INPUT-DENY:" comment="Log denied input"
add chain=input action=drop comment="Default deny input"

6.3 Role-Based Access Control for Router Management

# Create restricted user groups
/user group
add name=monitoring policy=read,api,winbox,web,sniff,!write,!policy,!test,!ftp,!reboot,!password,!ssh,!sensitive,!local,!telnet
add name=helpdesk policy=read,write,winbox,web,!policy,!test,!ftp,!reboot,!password,!sensitive,!local,!telnet,!ssh,!api,!sniff

# Create users with least-privilege groups
/user
add name=monitoring-svc group=monitoring password="MonitoringServicePass!" address=10.0.10.50/32 \
    comment="Monitoring service account - read only"
add name=helpdesk-user group=helpdesk password="HelpdeskPass!" address=10.0.10.0/24 \
    comment="Helpdesk - limited write"

# RADIUS authentication for admin users
/radius
add address=10.0.10.50 secret="RadiusAdminSecret!" service=login

/user aaa
set use-radius=yes default-group=read

6.4 Software and Patch Management

• Use the long-term release channel for production routers. Use stable only if you need specific features.
• Check for updates weekly. Do not enable auto-upgrade in production.
• Test updates in a lab environment before deploying to production.
• After a RouterOS upgrade, always upgrade the routerboard firmware: /system routerboard upgrade
• Maintain configuration backups before every upgrade: /export file=pre-upgrade-backup
• Document a rollback procedure using Netinstall.

# Automated update check (does NOT auto-install)
/system scheduler
add name=check-updates interval=7d on-event="/system package update check-for-updates" \
    start-time=03:00:00 comment="Weekly update check"

# Script to alert on available updates (via email or Telegram)
/system script
add name=update-alert source={
    /system package update check-for-updates once
    :delay 15s
    :local status [/system package update get status]
    :if ($status = "New version is available") do={
        :local ver [/system package update get latest-version]
        /tool e-mail send to="admin@example.com" subject="MikroTik Update Available" \
            body="RouterOS $ver is available on $[/system identity get name]"
    }
}

7. Phase 5 — Continuous Monitoring, Logging, and Analytics

↑ Back to Top

Zero Trust requires continuous verification. Logging and monitoring provide the visibility to detect policy violations, anomalous behavior, and active threats.

7.1 MikroTik Logging Architecture

Send all logs to a centralized syslog server. Do not rely on the local log buffer — it is volatile and size-limited.

# Remote syslog configuration
/system logging action
add name=remote-syslog target=remote remote=10.0.10.55 remote-port=514 \
    src-address=10.0.10.1 bsd-syslog=yes syslog-facility=local0

# Log topics to send remotely
/system logging
add topics=firewall action=remote-syslog
add topics=dhcp action=remote-syslog
add topics=system action=remote-syslog
add topics=ipsec action=remote-syslog
add topics=ppp action=remote-syslog
add topics=dot1x action=remote-syslog
add topics=error action=remote-syslog
add topics=critical action=remote-syslog
add topics=warning action=remote-syslog
add topics=account action=remote-syslog

What to log for Zero Trust:

• All firewall deny actions (the log-prefix rules from earlier sections)
• DHCP lease assignments and expirations
• 802.1X authentication successes and failures
• VPN connection and disconnection events
• System configuration changes
• Login attempts (successful and failed)
• Certificate events (expiration warnings, CRL updates)

7.2 NetFlow/IPFIX with Traffic Flow

Traffic Flow exports per-flow metadata (source, destination, protocol, port, bytes, packets) to a collector. This provides deep traffic visibility without capturing full packets.

# Enable Traffic Flow
/ip traffic-flow
set enabled=yes interfaces=all cache-entries=16384 active-flow-timeout=1m \
    inactive-flow-timeout=15s

# Export to collector (ntopng, Elastiflow, ManageEngine)
/ip traffic-flow target
add dst-address=10.0.10.56 port=2055 version=9 v9-template-refresh=60 \
    v9-template-timeout=1800

Use flow data to:

• Identify unexpected traffic between zones (a device in the IoT VLAN talking to the server VLAN should trigger an alert)
• Detect lateral movement within a zone
• Baseline normal traffic patterns to identify anomalies
• Validate that firewall rules are effective (flow data should show no unauthorized inter-zone traffic)

7.3 SNMPv3 Monitoring

Never use SNMPv1 or v2c in a Zero Trust environment. They transmit community strings in cleartext. Use SNMPv3 with authentication and encryption.

/snmp
set enabled=yes contact="noc@example.com" location="DC-Rack-A3" \
    trap-community="" trap-version=3

/snmp community
remove [find]   # Remove default "public" community

# SNMPv3 user with SHA auth and AES encryption
set [find] name=ztna-monitor security=private \
    authentication-protocol=SHA1 authentication-password="SNMPAuthPass123!" \
    encryption-protocol=AES encryption-password="SNMPEncPass456!" \
    read-access=yes write-access=no addresses=10.0.10.50/32

Key metrics to monitor:

• Interface utilization (sudden spikes may indicate exfiltration)
• CPU and memory usage (high usage may indicate a DoS or cryptomining)
• Firewall rule hit counters (rules with zero hits may indicate misplacement)
• Connection tracking table size (approaching limits causes dropped connections)
• Failed authentication attempts (brute-force indicator)
• BGP/routing table changes (if applicable)

7.4 Automated Threat Detection with Scripting

MikroTik scripting can detect and respond to threats automatically.

SSH brute-force detection and blocking with Telegram alert:

/ip firewall filter
# Detect SSH brute-force: more than 3 new connections in 1 minute
add chain=input protocol=tcp dst-port=2222 connection-state=new \
    src-address-list=ssh-bruteforce action=drop comment="Drop SSH bruteforce"
add chain=input protocol=tcp dst-port=2222 connection-state=new \
    src-address-list=ssh-stage3 action=add-src-to-address-list \
    address-list=ssh-bruteforce address-list-timeout=30d
add chain=input protocol=tcp dst-port=2222 connection-state=new \
    src-address-list=ssh-stage2 action=add-src-to-address-list \
    address-list=ssh-stage3 address-list-timeout=1m
add chain=input protocol=tcp dst-port=2222 connection-state=new \
    src-address-list=ssh-stage1 action=add-src-to-address-list \
    address-list=ssh-stage2 address-list-timeout=1m
add chain=input protocol=tcp dst-port=2222 connection-state=new \
    action=add-src-to-address-list address-list=ssh-stage1 \
    address-list-timeout=1m

# Telegram alert script (runs on scheduler every 5 minutes)
/system script
add name=alert-bruteforce source={
    :local botToken "YOUR_BOT_TOKEN"
    :local chatId "YOUR_CHAT_ID"
    :local hostname [/system identity get name]
    :foreach i in=[/ip firewall address-list find list=ssh-bruteforce] do={
        :local addr [/ip firewall address-list get $i address]
        :local comment [/ip firewall address-list get $i comment]
        :if ([:len $comment] = 0) do={
            /tool fetch url="https://api.telegram.org/bot$botToken/sendMessage" \
                http-method=post http-data="chat_id=$chatId&text=SSH Bruteforce blocked on $hostname: $addr" \
                keep-result=no
            /ip firewall address-list set $i comment="alerted"
        }
    }
}

/system scheduler
add name=bruteforce-alert interval=5m on-event="/system script run alert-bruteforce"

Threat intelligence feed integration (import blocklists):

/system script
add name=update-blocklist source={
    # Download Spamhaus DROP list
    /tool fetch url="https://www.spamhaus.org/drop/drop.txt" dst-path=drop.txt
    :delay 2s
    
    # Clear existing entries
    /ip firewall address-list remove [find list=blocklist-spamhaus]
    
    # Parse and import
    :local content [/file get drop.txt contents]
    :local lines [:toarray $content]
    :foreach line in=$lines do={
        :if ([:pick $line 0 1] != ";") do={
            :local subnet [:pick $line 0 [:find $line " "]]
            :if ([:len $subnet] > 0) do={
                /ip firewall address-list add list=blocklist-spamhaus address=$subnet timeout=1d
            }
        }
    }
    /file remove drop.txt
}

# Firewall rule to block traffic from blocklist
/ip firewall raw
add chain=prerouting src-address-list=blocklist-spamhaus action=drop \
    comment="Drop Spamhaus blocklist"

# Schedule weekly updates
/system scheduler
add name=update-blocklist interval=1d start-time=02:00:00 \
    on-event="/system script run update-blocklist"

7.5 SIEM Integration

Forward MikroTik syslog data to a SIEM platform for correlation and alerting:

• Wazuh — Open-source SIEM with built-in MikroTik log decoders. Configure syslog forwarding to the Wazuh manager and create custom rules for Zero Trust policy violations.
• Graylog / ELK Stack — Parse MikroTik logs with Grok patterns. Build dashboards for authentication events, firewall denies, and zone-crossing traffic.
• Splunk — Use the Splunk syslog input and create alerts for: “traffic from IoT VLAN to server VLAN” or “failed authentication count > 5 in 10 minutes.”

Example Wazuh detection rule (ZTNA policy violation):

<!-- Alert when firewall denies inter-zone traffic -->
<rule id="100100" level="10">
  <decoded_as>mikrotik-firewall</decoded_as>
  <match>FWD-DENY:</match>
  <description>MikroTik: Inter-zone traffic denied (Zero Trust policy violation)</description>
  <group>mikrotik,firewall,ztna_violation</group>
</rule>

<!-- Alert on repeated authentication failures -->
<rule id="100101" level="12" frequency="5" timeframe="300">
  <if_matched_group>mikrotik_auth_failure</if_matched_group>
  <description>MikroTik: Multiple authentication failures (possible brute-force)</description>
  <group>mikrotik,authentication,brute_force</group>
</rule>

8. Advanced ZTNA Techniques on MikroTik

↑ Back to Top

8.1 Dynamic Access Lists and Timed Policies

Zero Trust access should be time-bound. Use these techniques to limit access windows:

• RADIUS Session-Timeout: Forces re-authentication after a defined period (e.g., 8 hours). If the user’s account is disabled between sessions, access is revoked at the next timeout.
• Firewall time rules: Restrict access to business hours (shown in Section 5.4).
• Dynamic address list entries with TTL: Address list entries added by RADIUS or scripts automatically expire.
• Scheduler-based policy changes: Scripts that enable/disable specific firewall rules at scheduled times.

# Example: Add contractor to access list with 8-hour expiry
/ip firewall address-list
add address=10.0.100.15 list=acl-contractors timeout=8h comment="contractor-jane temp access"

8.2 Network Access Quarantine Zone

Devices that fail authentication, exhibit suspicious behavior, or have expired certificates are moved to a quarantine VLAN with restricted access.

Quarantine zone policy:

• Access to patching/update servers only (Windows Update, antivirus update servers)
• Access to an internal remediation portal (instructions for the user)
• DNS restricted to internal resolver
• All other access denied

# Quarantine firewall rules
add chain=forward in-interface=vlan99-quarantine dst-address=10.0.30.15 \
    protocol=tcp dst-port=443 action=accept comment="Quarantine: access to remediation portal"
add chain=forward in-interface=vlan99-quarantine dst-address=10.0.30.5 \
    protocol=udp dst-port=53 action=accept comment="Quarantine: DNS to internal resolver"
add chain=forward in-interface=vlan99-quarantine action=drop \
    comment="Quarantine: deny all other access"

RADIUS Change of Authorization (CoA): FreeRADIUS can send a CoA packet to MikroTik to dynamically reassign a user to the quarantine VLAN mid-session — without waiting for re-authentication. This requires the RADIUS CoA port (3799) to be accessible on the MikroTik device.

# Enable RADIUS CoA on MikroTik
/radius incoming
set accept=yes port=3799

8.3 East-West Traffic Control and Intra-VLAN Isolation

Zero Trust does not stop at inter-VLAN boundaries. Lateral movement within a VLAN is equally dangerous. Use MikroTik bridge port isolation to prevent direct device-to-device communication within the same VLAN.

# Private VLAN emulation via bridge port isolation
# Isolated ports can only communicate with non-isolated ports (the router)
/interface bridge port
set [find interface=ether2] port-isolation=yes comment="User port - isolated"
set [find interface=ether3] port-isolation=yes comment="User port - isolated"
set [find interface=ether4] port-isolation=yes comment="Server port - isolated"

# The bridge itself (router interface) is NOT isolated - it can communicate with all ports
# This forces all traffic through the router's firewall, even within the same VLAN

With port isolation enabled, two devices on VLAN 20 cannot communicate directly at Layer 2. All traffic between them must pass through the router’s firewall. This gives you firewall-level control over intra-VLAN traffic.

8.4 DNS-Based Access Control

DNS is a critical control point. Attackers use DNS for command-and-control communication, data exfiltration, and policy bypass (DNS-over-HTTPS).

# Force all DNS through the MikroTik resolver (or a trusted resolver)
/ip firewall nat
add chain=dstnat protocol=udp dst-port=53 action=redirect to-ports=53 \
    in-interface-list=!ZONE-WAN comment="Redirect all DNS to router"
add chain=dstnat protocol=tcp dst-port=53 action=redirect to-ports=53 \
    in-interface-list=!ZONE-WAN comment="Redirect DNS TCP to router"

# Block DNS-over-HTTPS (DoH) to common providers to prevent policy bypass
/ip firewall address-list
add address=1.1.1.1 list=doh-servers comment="Cloudflare DoH"
add address=1.0.0.1 list=doh-servers comment="Cloudflare DoH"
add address=8.8.8.8 list=doh-servers comment="Google DoH"
add address=8.8.4.4 list=doh-servers comment="Google DoH"
add address=9.9.9.9 list=doh-servers comment="Quad9 DoH"
add address=149.112.112.112 list=doh-servers comment="Quad9 DoH"

/ip firewall filter
add chain=forward dst-address-list=doh-servers protocol=tcp dst-port=443 \
    action=drop comment="Block DoH to known providers"

# DNS static entries for sinkholing malicious domains
/ip dns static
add name="malicious-domain.com" address=0.0.0.0 type=A comment="Sinkhole: malicious"
add name="known-c2-server.net" address=0.0.0.0 type=A comment="Sinkhole: C2"

For a more complete DNS filtering solution, redirect DNS to Pi-hole, NextDNS, or a dedicated DNS firewall and configure MikroTik to block all direct DNS queries that bypass the designated resolver.

8.5 API-Driven Automation and Orchestration

Manual configuration does not scale. For multi-site MikroTik deployments, automate Zero Trust policy deployment using the RouterOS REST API and configuration management tools.

Ansible playbook — Deploy Zero Trust firewall rules across multiple MikroTik devices:

# ansible-playbook deploy-ztna-firewall.yml

---
- name: Deploy ZTNA Firewall Rules to MikroTik Devices
  hosts: mikrotik_routers
  gather_facts: no
  connection: network_cli
  vars:
    ansible_network_os: community.routeros.routeros

  tasks:
    - name: Ensure forward chain default drop exists
      community.routeros.command:
        commands:
          - /ip firewall filter add chain=forward action=drop comment="Default deny forward" place-before=last

    - name: Add zone-based jump rules
      community.routeros.command:
        commands:
          - /ip firewall filter add chain=forward action=jump jump-target=USERS-TO-SERVERS in-interface-list=ZONE-USERS out-interface-list=ZONE-SERVERS place-before=last
          - /ip firewall filter add chain=forward action=jump jump-target=USERS-TO-WAN in-interface-list=ZONE-USERS out-interface-list=ZONE-WAN place-before=last

    - name: Add Users-to-Servers explicit allows
      community.routeros.command:
        commands:
          - /ip firewall filter add chain=USERS-TO-SERVERS action=accept dst-address=10.0.30.10 protocol=tcp dst-port=443 comment="Allow HTTPS to app server"
          - /ip firewall filter add chain=USERS-TO-SERVERS action=drop comment="Deny all other user-to-server"

    - name: Verify firewall rules
      community.routeros.command:
        commands:
          - /ip firewall filter print where chain=forward
      register: firewall_output

    - name: Display firewall rules
      debug:
        var: firewall_output.stdout_lines

RouterOS REST API (v7.x) example — Add a firewall rule programmatically:

# Using curl to add a firewall rule via REST API
curl -k -u admin:password -X PUT \
  https://10.0.10.1/rest/ip/firewall/filter \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "forward",
    "action": "accept",
    "src-address-list": "acl-engineering",
    "dst-address": "10.0.30.0/24",
    "comment": "API: Engineering server access"
  }'

9. Real-World ZTNA Implementation Scenario

↑ Back to Top

9.1 Scenario Description

• Organization: Mid-sized company, 200 users, 3 branch offices, 30 remote workers.
• Infrastructure: MikroTik CRS326 switches, CCR2004 core routers, hAP ax3 at branches.
• Current state: Flat Layer 2 network, VPN with full network access, password-based authentication, no centralized logging.
• Business requirements: SOC 2 compliance, contractor access restrictions, IoT isolation for building management systems.

9.2 Migration Plan

9.3 Lessons Learned and Common Pitfalls

• Do not implement all phases simultaneously. Segmentation must be stable before adding authentication. Authentication must be stable before restricting VPN access.
• Monitor before enforcing. Use log-only firewall rules for at least two weeks before converting to drop rules. This surfaces legitimate traffic flows you did not anticipate.
• Certificate management is the hardest operational challenge. Plan for certificate expiration, renewal automation, revocation procedures, and key storage before deploying certificate-based authentication.
• User communication is critical. Inform users before each phase. Provide clear instructions for certificate installation, MFA enrollment, and what to do if access is denied.
• Document every firewall rule. Each rule should reference a business requirement or a ticket number. Undocumented rules become orphaned rules — and orphaned rules become security holes.
• Test failover scenarios. What happens if the RADIUS server is down? Implement a local fallback user and a RADIUS timeout policy. Verify that VPN failover works correctly.
• Budget time for IoT and legacy devices. These devices often cannot support 802.1X or certificates. Plan for MAC Authentication Bypass, dedicated IoT VLANs, and compensating controls.

10. MikroTik ZTNA Implementation Checklist

↑ Back to Top

Segmentation

• ☐ VLAN scheme designed and documented with trust zone mapping
• ☐ Bridge VLAN filtering configured and enabled
• ☐ VRF deployed for high-isolation zones (IoT, Guest)
• ☐ Interface lists created for each zone
• ☐ Forward chain firewall rules with zone-based jump chains
• ☐ Default deny on forward chain
• ☐ DHCP snooping enabled
• ☐ Unused switch ports disabled
• ☐ Port isolation enabled on access ports

Authentication

• ☐ FreeRADIUS deployed and tested
• ☐ 802.1X configured on switch ports
• ☐ Dynamic VLAN assignment via RADIUS verified
• ☐ MAC Authentication Bypass configured for non-802.1X devices
• ☐ Quarantine VLAN for failed authentications
• ☐ Certificate Authority deployed (MikroTik built-in or external)
• ☐ Client and server certificates issued
• ☐ Certificate revocation list configured
• ☐ MFA integrated via RADIUS proxy (Duo/Azure MFA)

Remote Access

• ☐ IKEv2 or WireGuard VPN configured with certificate authentication
• ☐ Split tunneling restricted to authorized subnets per user role
• ☐ Per-user firewall rules via RADIUS address list assignment
• ☐ Session timeouts enforced
• ☐ Time-based access rules for contractors

Management Plane

• ☐ Unnecessary services disabled (Telnet, FTP, HTTP, Bandwidth Test, etc.)
• ☐ Management access restricted to management VLAN
• ☐ SSH hardened: strong crypto, key-based auth, non-default port
• ☐ Input chain firewall with default deny
• ☐ RBAC user groups configured with least-privilege policies
• ☐ Admin authentication via RADIUS
• ☐ Neighbor discovery restricted to management VLAN
• ☐ MAC server disabled on all interfaces

Monitoring

• ☐ Remote syslog configured with relevant topics
• ☐ Traffic Flow (NetFlow/IPFIX) enabled and exporting to collector
• ☐ SNMPv3 configured (v1/v2c removed)
• ☐ Brute-force detection and blocking scripts deployed
• ☐ Threat intelligence blocklists imported and scheduled for updates
• ☐ SIEM integration with alerting for ZTNA policy violations
• ☐ DNS enforcement rules active (redirect + block DoH)

11. Conclusion

↑ Back to Top

MikroTik RouterOS has the features to implement meaningful Zero Trust Network Access. VLANs, VRF, certificate-based authentication, 802.1X, RADIUS-driven dynamic policies, per-user firewall rules, and comprehensive logging — all of these capabilities exist in the platform today.

The gap is not in the hardware or software. The gap is in how engineers configure it.

Most MikroTik deployments run flat networks with password-based VPNs and minimal firewall rules. This guide provides a structured, phase-by-phase path from that state to a Zero Trust architecture:

1. Segment the network into trust zones with default-deny inter-zone policies.
2. Authenticate every entity using certificates, 802.1X, and RADIUS.
3. Restrict remote access to specific applications per user role.
4. Harden the management plane to prevent the router itself from becoming the weakest link.
5. Monitor continuously and alert on policy violations.

Zero Trust is not a product you purchase. It is a strategy you implement — incrementally, deliberately, and continuously. Start with segmentation this week. Even that single step reduces your attack surface dramatically.

MikroTik’s cost-effectiveness makes enterprise-grade security architecture accessible to organizations that cannot afford dedicated ZTNA appliances. The return on investment is clear: a $300 MikroTik router, configured with Zero Trust principles, provides stronger security than a $30,000 appliance left at factory defaults.

Configure it correctly. Verify continuously. Trust nothing.

Check our list of MikroTik guides

Additional Resources

• NIST SP 800-207: Zero Trust Architecture
• MikroTik RouterOS 7 Documentation
• CISA Zero Trust Maturity Model
• FreeRADIUS Documentation
• Wazuh SIEM Documentation
• Ansible RouterOS Collection