Buzzwords come and go, but what doesn’t is the knowledge that security will always be a foremost concern for organizations of all sizes. Zero Trust Architecture has gotten a lot of press the past few years, with some misunderstandings about what it constitutes and how far teams have to go to qualify as “zero trust.” However, a new focus on secure by design architecture could lay the groundwork for more comprehensive security, including Zero trust, that doesn’t hinder work efforts.
See also: Zero Trust at Scale with Identity-Centric Microsegmentation
What Zero Trust Gets Right and Where It Stops
Zero Trust Architecture (ZTA) replaced outdated perimeter-based models with the principle that no user, device, or system should be inherently trusted, whether it’s inside or outside the network. Every access request is verified explicitly, using context-aware signals like identity, device posture, location, and workload behavior.
Since we’re working with highly dynamic environments thanks to cloud-native apps, the rise of remote work, and increased reliance on hybrid infrastructure, the way we think about security had to change. In theory, this model offers stronger protection in these dynamic environments, but in practice, we’re seeing more and more things labeled “zero trust” that aren’t actually that, often because it gets misunderstood or misapplied.
Sometimes, it’s over-reliance on a checklist model: implement MFA, add some segmentation, and assume you’re covered. Others assume adopting a specific platform or toolset automatically makes their environment Zero trust-compliant. But zero trust isn’t any of those things. It’s a continuous strategy requiring clear policies, well-defined access controls, and the ability to monitor and enforce them at runtime.
The biggest hiccup? Zero trust assumes the systems it’s protecting were built with at least a baseline of security. If an application has insecure default credentials, a hardcoded token, or an unpatched API, strict access controls won’t stop an attacker who finds a way to bypass them.
This is Why Secure By Design Comes First
Zero trust rightfully tells you not to place too much faith in the system, but secure by design principles give the environment that critical baseline of safety in the first place. Security gets baked in from the very beginning rather than layered on after. This can reduce the number of potential vulnerabilities before a system ever reaches production. As examples, in a cloud-native environment, this could mean using hardened container images that aren’t bloated with unused packages, or enforcing least privilege in IAM policies and Kubernetes RBAC.
When these basics aren’t in place, zero trust has to work harder. It becomes reactive rather than strategic, scrambling to isolate workloads or cut off compromised access after something has already gone wrong. By contrast, when systems are secure by design, zero trust works as intended: it verifies access to components that are already hardened, already instrumented for observability, and already behaving predictably. The result is a more resilient security posture, one where each layer reinforces the next.
CISA’s guidance makes this point clear: the burden of security shouldn’t fall on users or under-resourced IT teams. It should be handled at the executive and development level, by teams building systems that are safer before anyone ever logs in.
What Secure by Design Looks Like in Practice
Secure by design is all about reducing avoidable risk before code ever runs in production. It isn’t seeking out a single platonic ideal of security perfection in architecture. It makes intentional design choices that minimize vulnerabilities, clarify system behavior, and ensure secure configurations are the default. Most critically, it makes sure security isn’t something users have to enable manually.
Based on guidance from CISA, NIST’s Secure Software Development Framework (SSDF), and CSA’s 2024 Top Threats to Cloud Computing report, here’s what secure-by-design cloud-native development looks like in practice:
- Hardened defaults: Services ship with encryption enabled, MFA supported, logging turned on, and access scoped down, no need for users to toggle these on later.
- Infrastructure as Code security: IaC templates are scanned automatically for risky patterns (e.g., overly permissive IAM roles, open security groups, or unencrypted volumes).
- Signed and verified artifacts: Container images and third-party packages include signed attestations and Software Bills of Materials (SBOMs), so teams know what’s inside.
- Memory-safe development: Where possible, critical services are written in memory-safe languages (e.g., Rust, Go) to avoid entire classes of bugs like buffer overflows.
- Built-in secure workflows: CI/CD pipelines perform automated static analysis, dependency scanning, and policy enforcement before merge, not after release.
In CISA’s words, secure by design means “products should be secure out of the box,” with “additional security features such as MFA, logging, and SSO available at no extra cost.” If it takes extra effort—or money—to harden a product, it’s not secure by design.
What This Means for Enterprise Teams
For security and engineering leaders, secure by design is an opportunity to reduce friction and long-term risk across the board.
- For developers: Pre-approved secure patterns and automation mean less time spent chasing configuration checklists and fewer late-stage security blockers.
- For security teams: Fewer vulnerabilities enter production, so teams can shift from patch triage to strategic threat detection and response.
- For operations: Systems behave more predictably, with fewer emergency interventions caused by insecure defaults or bad dependencies.
- For leadership: Reduces the chance of costly incidents, compliance failures, and public breaches—without slowing teams down.
And it lays a cleaner foundation for zero trust to succeed. It ensures the systems being protected are fundamentally safer, more observable, and more tightly controlled, making runtime enforcement more effective and less chaotic. If zero trust is ever going to work, it will need this baseline.
So why not implement secure by design right now?
If it’s so great, why isn’t it an automatic practice for all companies? As with many things, security is complex and companies don’t always have the perfect set of tools and talent to make it happen. They’re dealing with several key obstacles.
Business pressure to ship fast
Secure by design requires a little bit of slowing down to think ahead. Unfortunately, development teams are under constant pressure to move quickly. This might be pressure to launch new products or find fixes for pivots in a workforce (like a sudden work-from-home mandate?). Security work can sometimes slow that velocity, even if it might save time and money later. This reality is especially pronounced in under-resourced organizations.
Misaligned incentives
This is closely related to the above. Not a single person involved in decision-making is going to actively support “less”security. However, the metrics may not always prioritize what it takes to be secure. Again, those metrics are things like speed or growth. Harder to detect and quantify is the risk reduction. Without clear mandates, security becomes everyone’s responsibility but no one’s KPI.
Legacy systems and technical debt
So much of the discussion around security involves a vacuum. Build security in first. Prioritize it from the beginning. But the beginning of what? Enterprises with legacy systems dating back to the early days of the technical revolution can’t just decommission and start fresh. You can’t design something securely when it was never designed to begin with; it just evolved. Many organizations continue to operate within this riddle.
Skill and tooling gaps
Not every team has secure development training. Not every pipeline includes IaC scanning, artifact signing, or threat modeling as standard features. Even when secure by design is prioritized, it can fall apart without the right tools and cross-functional coordination.
Even more, many commonly used open-source tools and cloud services still ship with permissive access controls, exposed ports, and insecure authentication patterns. That places the burden on developers to harden things manually, often without support.
Secure by Design Sets the Stage for Everything Else
Security isn’t a single control or a quick fix. It’s the result of thousands of small decisions made early, often under pressure. Zero trust can help enforce access boundaries and reduce blast radius, but it can’t compensate for insecure systems. That’s where secure by design comes in.
And while secure by design takes effort upfront, it delivers far more in return. Those early choices could mean fewer misconfigurations, smaller attack surfaces, easier audits, and less time spent reacting to incidents. Once deployed, it makes security scalable and makes zero trust actionable. And it makes it easier for teams to build, deploy, and maintain systems that don’t fall apart under pressure.
Elizabeth Wallace is a Nashville-based freelance writer with a soft spot for data science and AI and a background in linguistics. She spent 13 years teaching language in higher ed and now helps startups and other organizations explain – clearly – what it is they do.
