Untangling the Language of Security
Secure by Design, Zero Trust, Least Privilege, Defence in Depth, and the Architecture Terms Boards Confuse
A Practitioner's Reference for Disambiguating Overlapping Security Principles
CyberCQR White Paper | 16 July 2026
Executive summary
Boards and executive teams increasingly hear the same handful of security terms in the same conversation — Secure by Design, Zero Trust, Least Privilege, Defence in Depth, Secure Configuration, and Network or Micro-Segmentation — often used as if they were interchangeable. They are not. Each term describes a different layer of a security programme: a design philosophy, an access-control principle, an architectural strategy, or a specific technical mechanism. Conflating them leads to a common and costly mistake: an organisation believes it has “done Zero Trust” because it has segmented its network, or believes it is Secure by Design because it enabled multi-factor authentication.
This paper sets out a single mental model — Philosophy → Principle → Strategy → Mechanism — that resolves most of this confusion in one move, then walks through each term in that hierarchy, states plainly where terms genuinely overlap and where they do not, and anchors every term to the design authority, standard, or real-world exemplar that defines it. A companion section extends the same treatment to the data-security and access-control vocabulary — masking, tokenisation, pseudonymisation, anonymisation, and zero-knowledge architectures — which is treated at a lighter, cross-referencing depth here because CyberCQR's dedicated Data Protection Techniques and Zero-Knowledge Architectures white papers already cover that ground in full technical depth.
1. The overlap problem
A typical boardroom exchange runs something like this: “we're Zero Trust” is offered as equivalent to “we've segmented the network,” which is offered as equivalent to “we mask our data.” Each statement may be true. None of them implies the others, and none of them alone constitutes a security architecture. The confusion is understandable — these terms genuinely share a common ancestry and a common philosophy — but the practical consequence of collapsing them together is that organisations invest in one mechanism, believe they have satisfied a much broader principle, and leave the remainder of their exposure unaddressed.
The fix is a simple structural distinction. Every term covered in this paper sits at one of four levels:
Philosophy — why you build this way (Secure by Design)
Principle — the rule you apply (Least Privilege, Data Minimisation)
Strategy — how principles compose into an architecture (Zero Trust, Defence in Depth)
Mechanism — the concrete, deployable control (micro-segmentation, tokenisation, MFA)
Most conflation in practice happens because a mechanism is compared directly to a strategy, or a principle is mistaken for a philosophy. The diagram below sets out this chain using the cluster of terms most often confused with one another.
Figure 1 — Philosophy, principle, strategy, and mechanism form a chain, not a set of synonyms.
The remainder of this paper works through each level, states each term's definition boundary precisely, names the confusion it is most often subject to, and cites the design authority or real-world exemplar that defines current best practice.
2. Core design philosophies
These terms describe when and why security is built in, not what specific control is applied. They set the intent that the principles, strategies, and mechanisms in later sections then carry out.
| Term | Definition boundary | Common confusion | Exemplar / authority |
|---|---|---|---|
| Secure by Design (SBD) | Security is embedded in architecture and engineering decisions from inception, not added after deployment. | Often used loosely to mean “secure by default”, which is a narrower, related but distinct commitment. | CISA, joint guidance with NCSC, ACSC and international partners |
| Secure by Default | The out-of-the-box configuration is safe without requiring the customer to take action. | Treated as a synonym for Secure by Design; SBD is a design-time commitment, Secure by Default is a shipped-state property. | CISA / NCSC joint Secure by Design and Secure by Default guidance |
| Privacy by Design | The data-protection-specific instance of Secure by Design, applied to personal data processing. | Assumed to be identical to SBD generally, rather than a scoped application of it to privacy. | UK GDPR Article 25; ICO guidance |
| Shift Left | A process and timing principle — security activity moves earlier in the development lifecycle. | Confused with SBD itself: Shift Left answers “when” security work happens, SBD answers “what” gets built. | DevSecOps practice; NIST Secure Software Development Framework (SP 800-218) |
CISA's guidance, developed jointly with international partners including the UK's NCSC, states that manufacturers building Secure by Design software take ownership of customer security outcomes across the product lifecycle, embrace radical transparency in vulnerability disclosure, and treat security as a leadership-level objective rather than an engineering afterthought1. A product can be Secure by Default — shipping with multi-factor authentication and logging enabled out of the box — without the manufacturer having followed Secure by Design engineering practices throughout its development; the two commitments are related but not the same audit.
3. Trust and access principles
This is the cluster of terms most frequently conflated in practice, because Zero Trust genuinely does operationalise several of the others. The table sets each term's own scope; the two diagrams that follow make the relationship visual.
| Term | Definition boundary | Common confusion | Exemplar / authority |
|---|---|---|---|
| Least Privilege | Each identity holds the minimum standing access required for its role, evaluated continuously. | Used interchangeably with Zero Trust. It is one input to Zero Trust, not the whole of it. | NIST SP 800-53 Rev. 5, control AC-6 |
| Need to Know | A content-scoped subset of least privilege, tied to classification or data sensitivity rather than role alone. | Merged with least privilege generally; Need to Know adds a sensitivity dimension least privilege does not by itself require. | CNSSI 1253; Bell-LaPadula model (see CyberCQR's classified/commercial convergence paper) |
| Separation of Duties | No single identity can complete a sensitive transaction alone; the action requires two or more parties. | Confused with least privilege; SoD is about splitting a task across identities, not minimising any one identity's scope. | SOX; NIST SP 800-53, control AC-5 |
| Just-in-Time / Just-Enough Access | The temporal dimension of least privilege — elevated access is granted on request and expires automatically. | Treated as a Zero Trust-exclusive feature; it is a least-privilege mechanism Zero Trust happens to rely on heavily. | Microsoft Entra Privileged Identity Management; AWS temporary security credentials |
| Assume Breach | An operating posture: design and monitoring assume some identity or system is already compromised. | Confused with “we have been breached”; it is a planning assumption, not an incident status. | Zero Trust doctrine; Microsoft Zero Trust guidance |
| Zero Trust / Zero Trust Architecture (ZTA) | A strategy composing continuous identity verification, least privilege, and micro-segmentation into one architecture with no implicit trust by network location. | The single most conflated term in this list — used as a synonym for VPN replacement, for a specific product, or for segmentation alone. | NIST SP 800-207; Google BeyondCorp |
NIST SP 800-207 states plainly that zero trust removes implicit trust granted to assets or accounts based solely on physical or network location, and that authentication and authorisation are discrete functions performed before every session rather than one-time events at login2. A key paradigm shift the standard documents is the move from controls based on network segmentation and isolation toward controls based on identity — which is precisely why segmentation and Zero Trust get conflated: segmentation was the prior generation's answer to the same problem Zero Trust now answers at the identity layer.
Figure 2 — The trust boundary itself moves: from a location around the network, to locations around zones, to a boundary re-drawn around every individual request.
The practical test for whether an architecture is genuinely Zero Trust, rather than merely well-segmented, is whether trust is ever granted implicitly because of where a request originates. If a workload inside a given VLAN can reach another workload in the same VLAN without a fresh authorisation check, that architecture is segmented — a real and valuable control — but it is not Zero Trust.
Because Zero Trust, Least Privilege, and Defence in Depth (covered next) are so often used as though they were the same idea, the diagram below separates what each contributes uniquely from the philosophy they genuinely do share.
Figure 3 — Shared assumptions versus each principle's distinct mechanism of enforcement.
4. Layered and resilience principles
| Term | Definition boundary | Common confusion | Exemplar / authority |
|---|---|---|---|
| Defence in Depth | Multiple independent security layers, such that the failure of any single control does not by itself produce a compromise. | Used loosely to mean “lots of security tools” rather than independent, non-correlated layers. | Originates in NSA layered-defence doctrine, adapted from military defensive strategy |
| Layered Security | In most vendor and practitioner usage, a synonym for Defence in Depth. | Presented as a distinct concept when it is, in almost all cases, the same idea under a different label. | — (terminology note, not a distinct standard) |
| Fail-Secure vs Fail-Safe | A design choice for how a control behaves on failure — denying access (fail-secure) or preserving availability (fail-safe). | Confused with resilience or high availability generally, rather than a specific failure-mode decision. | Physical access-control engineering, adapted to information security |
The one substantive distinction worth holding onto in this section is Fail-Secure versus Fail-Safe, because the correct choice is context-dependent rather than universally “more security is better”: a door lock that fails secure during a power cut protects a data centre, but a fire door that fails secure during the same power cut endangers people. Defence in Depth as a strategy has to specify, for each layer, which failure mode it intends.
5. Architecture and topology
This is the section most directly answering where a trust boundary physically or logically sits, and it is where the Zero Trust conflation most often shows up as a purchasing decision: buying a micro-segmentation product is sometimes mistaken for buying Zero Trust outright.
| Term | Definition boundary | Common confusion | Exemplar / authority |
|---|---|---|---|
| Network Segmentation | Coarse-grained division of a network into zones (VLANs, subnets) with controlled routing between them. | Used interchangeably with micro-segmentation; segmentation operates at the network/zone level, not the workload level. | PCI DSS segmentation guidance |
| Micro-Segmentation | Fine-grained, workload- or identity-level segmentation, typically enforced independent of network topology. | Assumed to require a full Zero Trust rollout; in practice it is one mechanism Zero Trust architectures use, but it can be deployed on its own. | Illumio; VMware NSX; Google BeyondCorp |
| Compartmentalisation | Isolation driven by data classification or sensitivity rather than network or workload topology. | Blurred with segmentation generally; compartmentalisation's boundary is defined by classification level, not network position. | Bell-LaPadula model; Cross Domain Solutions (see CyberCQR's classified/commercial convergence paper) |
| Trust Boundaries / Attack Surface Reduction | The design-time concept of where trust level changes in a system, independent of any specific control. | Treated as identical to segmentation; segmentation is one implementation of managing a trust boundary, not the concept itself. | Microsoft Threat Modelling guidance; STRIDE |
Illumio's own architecture material illustrates the mechanism cleanly: a flat, fully-meshed environment is divided into segments defined by workload identity and communication need, so that only the specific traffic each tier legitimately requires is permitted and every other path is denied by policy rather than merely left undiscovered by an attacker3. The illustration below follows that convention: a flat network where any host can reach any other, split into segments that interlock like puzzle pieces — each piece representing a tier with its own boundary, with only the specific cross-tier flows the application actually needs permitted, and everything else explicitly blocked.
Figure 4 — Segmentation as a jigsaw: workloads grouped by function, with only necessary cross-segment traffic permitted.
Segmentation and micro-segmentation reduce blast radius and support Zero Trust, Defence in Depth, and least privilege simultaneously — which is exactly why the term gets pulled into all three conversations. It is best understood as a mechanism that multiple strategies rely on, not as a strategy in its own right.
6. Configuration and hardening
| Term | Definition boundary | Common confusion | Exemplar / authority |
|---|---|---|---|
| Secure Configuration | A state-based, ongoing control — is the system currently configured in line with a defined secure baseline. | Conflated with Secure by Default; Secure by Default is a design-time shipped-state property, Secure Configuration is an operational, ongoing responsibility. | CIS Benchmarks; DISA STIGs |
| Configuration Drift / Baseline Management | The detection of deviation from an approved configuration baseline over time. | Treated as a one-time hardening exercise rather than a continuous monitoring discipline. | NIST SP 800-128 |
| Hardening | The practical act of applying secure configuration controls to a system. | Used as a catch-all term for “we did security,” obscuring which specific baseline was applied. | CIS Benchmarks; DISA STIGs |
CIS Benchmarks and DISA STIGs remain the two most widely adopted secure-configuration baselines in commercial and government environments respectively, and both are designed to be machine-checkable, which is what makes ongoing drift detection possible rather than a manual, point-in-time audit.
7. Data security and access
The techniques in this section have their own dedicated technical treatment in CyberCQR's Data Protection Techniques and Zero-Knowledge Architectures white papers, anchored to NIST SP 800-88 and SP 800-188. This section is intentionally scoped to boundary clarity rather than full technical depth: it exists to resolve the specific confusions that arise when these terms are used alongside the architecture and access vocabulary covered above, particularly the tendency to treat Zero-Knowledge as a synonym for “encrypted” or “anonymised” rather than as a distinct proof mechanism.
| Term | Definition boundary | Common confusion | Exemplar / authority |
|---|---|---|---|
| Data Minimisation | The governing principle underpinning the rest of this section: collect and retain only the data a purpose requires. | Treated as a synonym for masking or anonymisation, when it is the upstream governance principle those techniques help satisfy. | UK GDPR Article 5(1)(c) |
| Masking | Obfuscation of data values, often reversible, typically applied to non-production or display contexts. | Confused with tokenisation; masking obscures a value in place, it does not necessarily generate a separately-managed surrogate. | NIST SP 800-188 (see CyberCQR's Data Protection Techniques paper) |
| Tokenisation | Replacement of a sensitive value with a format-preserving surrogate token, reversible only via a separately secured vault. | Confused with encryption; tokenisation is not a cryptographic transform of the value itself, and the token carries no derivable relationship to the original. | PCI DSS tokenisation guidelines; NIST SP 800-188 |
| Pseudonymisation | A GDPR-defined middle ground: data that can be re-identified only with additional information held separately. | Frequently conflated with anonymisation; the distinction is legally significant, as pseudonymised data remains personal data under GDPR and anonymised data does not. | UK GDPR Article 4(5) |
| Anonymisation | Irreversible removal of identifying characteristics, such that the data is no longer personal data. | Assumed to be synonymous with pseudonymisation; anonymisation is a stronger, one-way guarantee. | ICO Anonymisation Code of Practice |
| Encryption | A cryptographic transform reversible only with a key; not identity-aware and not format-preserving. | Confused with tokenisation, which is not cryptographic and does not require key management for the surrogate value itself. | NIST SP 800-57 (cross-reference only) |
| Differential Privacy | Statistical noise injected at the query or aggregate level to protect individuals within a dataset. | Confused with anonymisation of individual records; differential privacy protects the population-level output, not any single stored record. | NIST guidance; large-scale implementations at Apple and Google |
| Zero-Knowledge | A cryptographic architecture proving a fact about data is true without revealing the underlying data itself. | The most conflated term in this table — routinely used as a loose synonym for “encrypted” or “anonymised”, when it is neither; it is a proof mechanism, not a data-transformation technique. | NIST SP 800-188; zkSNARKs (see CyberCQR's Zero-Knowledge Architectures paper) |
The single most useful distinction to carry out of this section: masking, tokenisation, pseudonymisation, anonymisation, and encryption all transform a data value in some way. Zero-Knowledge does not transform the data at all — it proves a property of the data to a third party who never sees the value, which is a fundamentally different guarantee and the reason it belongs in its own category rather than alongside the others.
8. Case studies
8.1 Google BeyondCorp — Zero Trust from first principles
Google's BeyondCorp programme is the most frequently cited real-world exemplar of Zero Trust architecture, and its origin is instructive precisely because it began as a response to a segmentation and perimeter failure.
In January 2010, Google disclosed that it had been the target of a sophisticated, nation-state-linked intrusion, later named Operation Aurora, in which attackers exploited an unpatched vulnerability in Internet Explorer to gain a foothold and moved through Google's internal network, ultimately affecting more than twenty other organisations4. Google's internal response, developed and documented publicly between 2014 and 2018, replaced network-perimeter trust with a model in which every application request is authenticated and authorised based on user and device identity, regardless of whether the connection originates inside or outside a Google office5. BeyondCorp predates NIST SP 800-207 by six years and is widely credited as the architecture that demonstrated Zero Trust could operate at enterprise scale, rather than as a theoretical model.
Lesson for readers of this paper: BeyondCorp is frequently cited as “what Zero Trust looks like” without noting that Google explicitly moved away from network segmentation as its primary control, replacing it with identity- and device-centric authorisation applied to every request. Organisations that segment their network and stop there have not replicated BeyondCorp's actual architectural decision.
8.2 Target Corporation, 2013 — what happens without segmentation or least privilege
The Target breach remains the standard teaching case for what a flat, unsegmented network with excessive standing access looks like in practice.
Attackers obtained network credentials from a third-party HVAC contractor, Fazio Mechanical Services, via a phishing email, and used those credentials to reach Target's internal network through a vendor portal that was not adequately segmented from the payment-card environment. From that initial foothold, attackers moved laterally to point-of-sale systems and installed BlackPOS malware, ultimately exposing payment card data for roughly 40 million customers and personal information for a further 70 million6. The breach was detected by Target's own security tooling, but the alerts were not acted on in time — a reminder that segmentation and monitoring are complementary controls, and a failure of either can undermine the other.
Lesson for readers of this paper: this is a textbook Network Segmentation and Least Privilege failure, not primarily a Zero Trust failure in the modern sense — Zero Trust as an architecture was not yet in mainstream use in 2013. The applicable lesson today is that a vendor-access boundary is exactly the kind of trust boundary Section 5's jigsaw model is designed to enforce: the HVAC vendor's segment should never have had a path to the payment-card segment at all, regardless of stolen credentials.
9. Conclusion
None of the terms in this paper are wrong to use together — they describe a genuinely coherent, interlocking security architecture, and that coherence is exactly why they get spoken about as though they were interchangeable. The distinction that resolves almost every confusion in practice is level: philosophy, principle, strategy, and mechanism are four different kinds of claim, and a true statement at one level does not imply a true statement at another. An organisation that has hardened its configuration baseline (mechanism) has not thereby achieved Secure by Design (philosophy). An organisation that has segmented its network (mechanism) has not thereby achieved Zero Trust (strategy). Holding that distinction in view is, in practice, most of what it takes to have a precise conversation about security architecture in the boardroom rather than a marketing conversation.
Glossary
Attack surface — The complete set of points at which an unauthorised user could attempt to enter or extract data from a system.
Blast radius — The scope of systems or data that a single compromised identity, device, or control can reach.
Compartmentalisation — Isolation of information or systems based on classification or sensitivity level, independent of network topology.
Continuous verification — Re-evaluating trust for every request, rather than relying on a single prior authentication event.
Defence in Depth — A strategy of multiple, independent security layers such that no single control failure results in compromise.
Differential privacy — A statistical technique that adds calibrated noise to query results to protect individual records within a dataset.
Encryption — A reversible cryptographic transformation of data, requiring a key to recover the original value.
Fail-secure / fail-safe — A design choice governing whether a control denies access (fail-secure) or preserves availability (fail-safe) upon failure.
Hardening — The practical application of secure configuration settings to reduce a system's exploitable surface.
Least privilege — The principle that an identity should hold only the minimum access required to perform its function.
Masking — Obfuscation of a data value, often reversible, typically used in non-production or display contexts.
Micro-segmentation — Fine-grained, workload- or identity-level network segmentation, independent of physical topology.
Need to know — A content-scoped variant of least privilege, tied to data classification or sensitivity.
Network segmentation — Division of a network into zones with controlled routing between them.
Pseudonymisation — Data transformation such that re-identification requires additional information held separately, per UK GDPR Article 4(5).
Secure by Default — A product configuration in which the safest settings are enabled without requiring customer action.
Secure by Design — An approach in which security requirements are integrated into architecture and engineering from inception.
Secure configuration — An ongoing, state-based control verifying that a system matches an approved security baseline.
Tokenisation — Replacement of a sensitive value with a surrogate token, reversible only via a securely managed vault.
Trust boundary — The design-time point at which the level of trust applied to a request or data flow changes.
Zero-knowledge — A cryptographic method of proving a fact about data is true without revealing the underlying data.
Zero Trust / Zero Trust Architecture — A strategy in which no request is implicitly trusted based on network location; every request is independently authenticated and authorised.
Further reading
NIST SP 800-207, Zero Trust Architecture — the definitive federal reference architecture
NIST SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications
CISA / NCSC / ACSC, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software
CyberCQR White Paper, Data Protection Techniques — full technical treatment of masking, tokenisation, anonymisation and differential privacy
CyberCQR White Paper, Zero-Knowledge Third-Party Data Sharing Architectures
CyberCQR White Paper, Convergence of Commercial and Classified Information Architectures
CIS Critical Security Controls and CIS Benchmarks
PCI Security Standards Council, PCI DSS v4.0 tokenisation and segmentation guidance
References
1. Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software
CISA, with NSA, FBI, NCSC-UK, ACSC and international partners, October 2023 update
Establishes three core Secure by Design principles: take ownership of customer security outcomes, embrace radical transparency and accountability, and lead from the top.
https://www.cisa.gov/securebydesign
2. SP 800-207, Zero Trust Architecture
National Institute of Standards and Technology, August 2020
Defines zero trust as removing implicit trust granted by network location; establishes continuous, per-session authentication and authorisation as core tenets.
https://csrc.nist.gov/pubs/sp/800/207/final
3. Adaptive Micro-Segmentation Architecture
Illumio
Illustrates workload-identity-based segmentation, where permitted traffic is defined by application communication need rather than network topology.
https://www.illumio.com/
4. Operation Aurora disclosure and analysis
Google Security Blog (2010); subsequent industry analysis
Documents the January 2010 disclosure of a nation-state-linked intrusion into Google's corporate infrastructure that catalysed the BeyondCorp programme.
https://googleblog.blogspot.com/2010/01/new-approach-to-china.html
5. BeyondCorp: A New Approach to Enterprise Security
Ward, R. and Beyer, B., Google, published in ;login:, USENIX, 2014
The foundational BeyondCorp paper describing identity- and device-based access replacing network-perimeter trust at enterprise scale.
https://research.google/pubs/beyondcorp-a-new-approach-to-enterprise-security/
6. Target Corporation data breach analysis
Widely reported; original investigative reporting by Krebs on Security, 2014
Documents the 2013 breach originating from compromised third-party vendor credentials and a lack of segmentation between the vendor portal and payment-card environment.
https://krebsonsecurity.com/
7. SP 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organisations
National Institute of Standards and Technology
Source for the Least Privilege (AC-6) and Separation of Duties (AC-5) control definitions used throughout this paper.
https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
8. SP 800-188, De-Identifying Government Datasets
National Institute of Standards and Technology
Standards basis for masking, tokenisation, and de-identification terminology; see CyberCQR's Data Protection Techniques paper for full treatment.
https://csrc.nist.gov/pubs/sp/800/188/final
9. UK General Data Protection Regulation, Articles 4(5), 5(1)(c) and 25
UK Government / ICO
Legal basis for the pseudonymisation, data minimisation, and privacy by design definitions used in this paper.
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/
10. PCI Data Security Standard v4.0
PCI Security Standards Council
Standards basis for network segmentation scope-reduction and tokenisation guidance in the payment card industry.
https://www.pcisecuritystandards.org/
11. CNSSI 1253, Security Categorisation and Control Selection for National Security Systems
Committee on National Security Systems
Source for compartmentalisation and Need to Know terminology in classified environments; see CyberCQR's classified/commercial convergence paper.
https://www.cnss.gov/