“Make it secure” is not a design requirement.
A security architect has to turn that request into decisions. Which assets matter? Who needs access? Where can an attacker move? Which failures can the business tolerate? What evidence will show that the controls still work six months later?
Security architecture connects those decisions. It is not a diagram filled with product logos. It is the reasoning behind the trust boundaries, controls, and recovery paths in a system.
I will use a small billing service as the running example. Customers sign in through a web application. The application calls a billing API, which reads account data from a database. Support staff can issue refunds, and engineers administer the service through a separate management path.
Start with the system, not the controls
Before selecting a firewall, identity provider, or monitoring platform, describe the system in plain language:
- What data does it process?
- Where does that data enter, move, and leave?
- Which people, services, and third parties can reach it?
- What would an attacker gain by compromising it?
- How long can the service be unavailable?
This creates a threat model that is specific enough to guide design. Without it, teams tend to copy a standard control list and call the result architecture.
For the billing service, payment and account data matter most. Stolen customer credentials, an exposed API, a compromised support account, and an engineer’s admin session create different paths and need different controls.
Put identity before network location
Network location is weak evidence of trust. A device on the corporate network may be unmanaged, compromised, or operated by someone using stolen credentials.
Access decisions should use identity, device state, requested resource, and risk. Administrators need stronger controls than ordinary users. Service accounts need ownership and a limited purpose. Temporary access should expire without relying on someone to remember a ticket.
Least privilege is the goal, but it needs an operating process. Define who approves access, how the system records it, and how often owners review it. “Role-based access” on a diagram proves very little if every role contains broad permissions.
A support role may view an account and request a refund but should not change deployment settings or query the database. An engineer may deploy the API without receiving access to customer payment data.
Use segmentation to limit failure
Segmentation reduces how far an attacker or mistake can spread. Production, development, management, and user networks should not share unrestricted paths. Sensitive applications may need smaller boundaries around databases, administrative interfaces, or processing tiers.
The useful question is not whether segmentation exists. Ask what a compromised endpoint can reach next.
In the example, the public web tier can call the billing API on one service port. It cannot connect directly to the database or management network. The API can reach the database, but the database cannot initiate connections back to the web tier.
Firewalls, security groups, ACLs, service meshes, and identity-aware proxies can enforce these boundaries. The choice depends on where the traffic flows and who manages the control. My deeper guides cover firewall deployment and hardening and firewall compliance.
Assume one control will fail
Defense in depth is often drawn as a stack of products. That misses the point. The layers should fail differently.
If an attacker steals a password, MFA should block its use. If the attacker steals a session, device checks and scoped authorization should limit access. If malicious activity reaches an endpoint, EDR should detect it. If detection is late, segmentation and protected backups should reduce the damage.
Several products that depend on the same identity source, policy error, or administrative account may represent one failure path rather than several layers.
Design the evidence with the control
A control that nobody can verify will decay quietly.
For each important control, decide what evidence it produces and who reviews that evidence. Firewall rules need owners, reasons, review dates, and logs. Privileged access needs approvals and session records. Recovery plans need restore tests, not screenshots of a backup console.
A refund should leave the support identity, customer account, amount, approval, and result in the audit log. A deployment should record a different identity and change reference. Mixing both under one shared administrator account destroys that distinction.
This is where compliance can help. A good control can meet a regulatory requirement and reduce a real attack path. A bad compliance program collects documents without checking whether the system behaves as described.
Plan for detection and recovery
Prevention will miss something. Architecture should define how the team detects a problem, contains it, restores service, and learns from the incident.
Logging needs enough context to answer who did what, to which resource, and from where. Alerts need an owner and a response path. Backups need isolation and restore tests. Critical services need recovery objectives that the business has accepted.
Cloud services do not remove these responsibilities. Providers secure their infrastructure. You still own identities, configuration, data access, application code, and most of the evidence used during an investigation.
For the billing service, recovery means more than restoring a database backup. The team must reconcile payments created after the backup, rotate exposed credentials, validate the application path, and prove that refund and deployment logs are complete.
A practical architecture review
When I review a design, I want clear answers to five questions:
- What are we protecting, and from whom?
- Where does the system make trust decisions?
- What can an attacker reach after one control fails?
- How will the team know that a control failed?
- How will the service recover?
Products come after those answers. A diagram may change as the system grows, but the reasoning should remain traceable.
For a closer look at identity-led access, see Zero Trust: Why the Perimeter Model Is Dead.