What does Security Architect actually do?
I have spent over 15 years working hands-on across Telecom, Vendor, System Integration, and Automotive in areas including Network, Systems, Application, Cloud, and AI. Working across so many different fields gave me something I did not fully appreciate at the time: the ability to see the full picture while still understanding the details. That has been valuable both to me and to the organizations I have worked with, especially in recent years when my focus shifted to security architecture and hardening. I kept having these conversations with colleagues but never wrote any of it down for a wider audience. This article is my attempt to fix that.
I have observed that the role of a security architect in cybersecurity is not fully understood and is sometimes misaligned within companies. In this piece I will try to explain what the Security Architect role actually involves, how it relates to other roles, and what kind of background someone needs to do it well. I will keep it practical and based on what I have seen firsthand.
Who missed the vulnerability?
When a security vulnerability is discovered in an organization, a few questions tend to follow.
- How did we miss this?
- Could we have detect it earlier?
- How long will it take to fix and what will it cost?
The answer usually points back to the same place: the early decisions made during design and development.
When a vulnerability is found in an IT application or system, the system owner or application team is usually the first to be held accountable. That is sometimes fair, but in environments with complex requirements and dependencies, system administrators and developers can fall short when it comes to identifying security risks. This is not because they do not know their systems well, or because they are not good at what they do. It comes down to a gap in threat awareness. Their primary responsibility is ensuring users and systems can reach each other, making sure requests are handled correctly according to business needs, and keeping up with heavy workloads. Because of these competing demands, they often do not have enough time to research security threats, assess risks, and stay current on the measures needed to address them.
There is also a structural reason why this happens. No one sees the weaknesses in something they built as clearly as someone coming in from outside. This applies to security teams too. Even an experienced security administrator will tend to underestimate risks in systems they manage themselves. The principle of separation of duties exists for exactly this reason: the person conducting a review should not be the same person being reviewed.
In complex environments, another pattern comes up regularly. Each team manages its own risks, but no one is looking at the overall picture. but attackers are.
For instance a development team that believes access to their application is IP-restricted may not put much effort into authentication, authorization, and session management, assuming the network layer already covers it. The network team, on the other hand, may treat the IP restriction as sufficient and assume the application has its own controls. Neither team stops to think about what the security posture looks like behind those allowed IP addresses.
Both teams received a request. Both completed their task on time. What gets skipped is the question of what happens if one layer fails. What needs to be in place across the rest of the system to keep the risk contained? If the allowed IP address belongs to a network outside the organization’s control, weak security on that network could give unintended users access to an application that was never meant to be reachable from outside. I have run into this kind of layered assumption failure more times than I can count.
What does a Security Architect do?
A security architect designs how a system should be set up to minimize security risks. Network segmentation, identity management, data classification, access controls, encryption standards: none of these are independent decisions. The Security Architect’s job is to look at all of them together, anticipate where the overall design can be broken, and specify controls that reduce risk to an acceptable level given the data and operations involved.
The standard method for doing this is threat modeling. Frameworks like STRIDE, PASTA, and MITRE ATT&CK can surface how a system not yet built could be attacked. What makes these tools useful is not knowing the frameworks themselves. It is knowing when and how to apply them given the specific context.
In the Capital One breach (2019), the attacker accessed a metadata service through a misconfigured WAF in the AWS environment, gaining access to millions of customer records. Technically, this was a design flaw at the intersection of cloud security, network architecture, and IAM policies. The root cause was not code, but architectural decisions. It was a breach resulting from weaknesses arising from the integration between system components. Not a single component, the failure of multiple security controls.
One of the causes was the default configuration and access settings in AWS’s metadata service, which did not provide customers with sufficient control. Additionally, granting the WAF service excessive permissions, the IAM role being able to decrypt data despite encryption, and the lack of monitoring of IAM and S3 service activities for anomalies, allowing the WAF to connect as an “open reverse proxy” due to a lack of full understanding of the interaction between the WAF’s reverse proxy settings and the cloud infrastructure, and the inability of the WAF solution to determine whether the IP addresses connecting to the application were VPN IPs. These and many other chained deficiencies contributed to the inability to prevent this breach.
We ran a pentest and vulnerability scans. Is that not enough?
Penetration testing and vulnerability scanning are genuinely valuable. They identify vulnerabilities, document causes, and assess potential impact. But they measure what is currently present and reachable. Design-level risks that exist before any code is written or infrastructure is deployed fall outside their scope.
Get TUNA ASLAN’s stories in your inbox
Join Medium for free to get updates from this writer.
There are also practical limits. Results depend on the tester’s skill, the time allocated, how closely the test environment mirrors production, and what changes after the test is done. Chained configuration weaknesses like the ones in the Capital One breach are not the kind of thing vulnerability scanners find or pentesters easily exploit. They are difficult to uncover in a limited time and knowledge about the system itself.
There is a more fundamental issue too. A pentest professional who cannot exploit a vulnerability during a test may reasonably classify it as low risk. But a new service added later, a change in the type of data being processed, or an integration with another component could make that same vulnerability exploitable. Architectural analysis and threat modeling address these not-yet-realized scenarios in a way that testing cannot. “This cannot be exploited right now” and “this does not present a high risk” are not the same thing.
There is also a pattern worth noting at the organizational level. Annual pentest reports across different applications often contain the same findings year after year: legacy protocols, overprivileged service accounts, segmentation gaps. Patches get applied to each application, but the same issues appear in others the following year. When findings are never addressed at the architectural level, the root cause stays in place and remediation restarts with every new project. That cycle has a real cost.
Is an Offensive Background Enough to Make a Security Architect?
Offensive background is a strong foundation for security architecture. Someone who has internalized the attacker’s perspective brings real value to threat modeling. But a career focused primarily on offensive security is unlikely to be sufficient on its own. Missing knowledge in other security domains create blind spots in architectural thinking.
Security architecture sits at the intersection of multiple disciplines: network design, identity and access management, logging and monitoring, application security, cloud infrastructure, data governance, and compliance. Meaningful depth across these areas, and the ability to see how they affect each other, is what the role requires.
Someone focused exclusively on application security will analyze OWASP vulnerabilities well but may not see the lateral movement risk within the same application’s service mesh. Someone working purely in network security will get VLAN segmentation right but may miss a weak link in the authentication chain at the API gateway. These are not personal failings. They are the inevitable consequence of specialization. The Security Architect’s role is built around seeing exactly these gaps. That perspective develops over years of working across different roles, sectors, and threat environments and experiencing different scenarios.
Why does experience matter so much?
Certifications are a reasonable starting point. CISSP, SABSA, and TOGAF provide a useful conceptual framework. But security architecture is full of questions no certification exam covers.
How do you assess the infrastructure of a company being acquired? How do you balance usability against security requirements during a zero trust transition? Which on-prem controls become obsolete when moving to the cloud, and how should their equivalents be structured? Can an existing security architecture support an organization that is scaling rapidly? These questions require someone who has been in the field. Not just someone who knows what the right answer looks like in theory, but someone who knows what is actually workable under real constraints.
Sector experience matters for the same reason. Data classification requirements in banking, HIPAA obligations in healthcare, classification tiers in defense, and PCI DSS scoping in e-commerce each impose very different constraints. You can learn about these environments through reading. Making sound decisions inside them requires having worked there.
Why does early involvement matter?
When a Security Architect is involved from the start of a project, security requirements become part of the design rather than something added afterward. When they are brought in late, the cost of correcting course grows quickly. Rework takes engineering time. It causes schedule delays. It sometimes introduces licensing or external support costs tied to requirements that surface too late in the process.
A security gap found just before go-live almost always means significant rework. That rework delays not just the current project but everything else waiting in the queue. Catching these issues during design, before anything is built, substantially reduces that cost. It is not only about implementing security controls but also deciding where to implement.
A concrete example: a new application is being built to process cardholder data. If the data flow is not designed correctly and that data ends up in the wrong segment, PCI DSS scope expands unnecessarily. Dozens of systems that should have been out of scope fall under audit requirements. That difference can translate to hundreds of thousands of dollars in annual compliance costs, and it repeats every year. A single architectural decision made early could have prevented it.
When security is built in from the start, it is a design decision. When it is added afterward, it is either a patch or an accepted risk. The cost difference between those two is usually significant.
Identifying problems is not enough
The two most common failure modes in security architecture are exact opposites of each other. The first is dismissing a risk without fully understanding its impact: the “nothing will happen” instinct. The second mistake is to treat every finding as a critical threat; this unnecessarily drives up costs and ultimately undermines your credibility with the teams you’re supposed to be helping. Both of these reflect a lack of experience.
Assessing what a risk actually means requires looking at it in context. How critical is the application? What controls are already in place? What does the planned development roadmap look like? Some risks can be brought to an acceptable level through well-designed compensating controls rather than expensive technical overhauls. Others look minor on the surface but have the potential to cascade across the wider system.
The ability to make that distinction is probably the most important skill a Security Architect can have. Technical knowledge provides the foundation but does not get you there on its own. A Security Architect should be the person who says not “this cannot be done” but “here is how it can be done, and here are the controls that keep the risk manageable.” That difference determines whether security works alongside the business or against it.
Final thoughts
Being a Security Architect does not mean knowing everything better than everyone else. It means being able to see how different disciplines affect each other, how a decision in one place creates consequences somewhere else, and what a risk actually means in its specific context. That perspective is not built by going deep in a single domain. It is built by working across different environments, different threat landscapes, and different teams over many years. Certifications like CISSP, threat modeling training, and similar programs can help fill some of that gap, but they are a starting point, not the last target.
Organizations typically recognize the need for this kind of end-to-end security thinking not before something goes wrong, but after. That is slowly changing, driven by new regulations, lessons learned after incidents, and growing experience across the industry. But slowly is still the operative word.
