Vaal Consulting — You build Zero Trust

Architecture & Strategy

Products help.

— But only once you first adopt the principles and apply them consistently.

Everyone is talking about Zero Trust. Vendors promise it in a product or service. But at its core, Zero Trust is not a tool; it is an architectural choice and a way of designing. Tooling can help—significantly, even—but only after you have translated the principles into coherence: what you protect, how access is decided, where you enforce it, and how you measure it.

That is why Zero Trust begins with architecture.

I help organizations translate Zero Trust from a "good idea" into a buildable design and roadmap that teams can build and that governance/audit can follow—vendor-neutral and pragmatic.

You can't design anything of any complexity without architecture. Architecture is the basis for all design.

— John A. Zachman

Misconceptions

Seven Myths about Zero Trust

Zero Trust is not a technology. It is a mindset and design principle. Tooling can provide support, but only if you first determine what you are protecting, who or what requires access, and how you enforce it.

Zero Trust is not a technology. It is a mindset and design principle. Tooling can provide support, but only if you first determine what you are protecting, who/what requires access, and how you enforce it.

Zero Trust is never 'finished'. It is a continuous way of designing and improving. Your environment changes—so your controls, policies and validation must evolve along with it.

Organizations that have rolled out MFA, VPN-less access or ZTNA sometimes claim "we have Zero Trust." In reality, you are mainly addressing identity/access, but not your entire attack surface. Zero Trust requires consistent principles across identity, device posture, network/micro-segmentation, applications and data; MFA or ZTNA alone is a useful component, not an end state.

Another variant is the reduction to "Zero Trust = IAM + IdP + MFA." Identity is a strong signal, but not the only decision point. Zero Trust decisions combine context: identity, device health, location, behavior, the sensitivity of the resource and real-time signals from monitoring/telemetry.

Sometimes Zero Trust is sold to the board as "if we do this, we are secure." No model offers 100% certainty; Zero Trust reduces risk and lateral movement, it does not eliminate them. The real value is: a smaller blast radius, shorter dwell time and better detection when (not if) something goes wrong.

Smaller organizations often think Zero Trust is "overkill" or only relevant above a certain scale. In practice, many Zero Trust principles are actually very applicable at a small scale: explicit policies, least privilege, segmentation and continuous validation of access are just as valuable for an SME tenant as for a bank.

There is still often the perception: more checks = worse UX (user experience). If you roll out Zero Trust naively (extra prompts everywhere, manual approvals) that holds true. With adaptive policies, risk-based access and good integration, Zero Trust can actually improve UX: less always-on VPN, more direct access to specific apps, and friction only when the risk level rises.

Foundation

Five Core Principles of Zero Trust

01

Never trust, always verify

Every request is validated on identity + context.

02

Least privilege

The minimum necessary permissions, including for service accounts and non-human identities.

03

Protect surface & micro-segmentation

Protect what matters, design "micro-perimeters".

04

Assume breach

Design for impact reduction and rapid containment.

05

Continuous monitoring & validation

Access is not static; behavior and posture are continuously taken into account.

These five pillars form the minimum assessment framework for design, implementation and continuous improvement.

Discover how I can help you

Transitioning to ZTA (Zero Trust Architecture) is a journey concerning how an organization evaluates risk in its motion and cannot simply be accomplished with a wholesale replacement of technology.

— National Institute of Standards and Technology (NIST) SP 800

Approach

Build a Zero Trust architecture

Based on the high-level Zero Trust steps developed by John Kindervag. I assist organizations in commencing their Zero Trust journey: from principle → design → implementation roadmap.

Specifically, I deliver:

Protect Surface & DAAS inventory — what you must protect and why.
Transaction flows — how data and requests truly flow, including chains.
Target architecture — segmentation, identity, policy enforcement, logging/telemetry.
Policy model — who/what/where/when/how + exceptions with governance.
Roadmap — step-by-step, iterative, aligned with maturity and priorities.
Vendor reality check — integrating tools into the design, not the reverse.

Updates · Jan 2026

OT environments continue to be targets; ransomware + geopolitical threat.

So tool selection is not the starting point.

Design first, then choices.

Step 1

Define (protect surface)

Step 2

Model (flows + policy)

Step 3

Design & plan (enforcement + telemetry + 30/60/90 backlog)

Book a call

You can't buy Zero Trust.You build it.

Products help.

Seven Myths about Zero Trust

Five Core Principles of Zero Trust

Never trust, always verify

Least privilege

Protect surface & micro-segmentation

Assume breach

Continuous monitoring & validation

Build a Zero Trust architecture

Top 10 Cyber Threats to Watch

Ransomware & data extortion

Phishing & social engineering

Supply chain vulnerabilities

Insider threats

Credential theft & identity attacks

Exploited vulnerabilities & zero-days

Cloud misconfigurations & API exposure

AI scams & deepfake impersonation

DDoS / disruption

OT/ICS & IoT attacks

So tool selection is not the starting point.

You can't buy Zero Trust.
You build it.