Security Architect isn't a starting point. It's what can happen once you've spent enough time learning how technology actually works, how it fails, how it gets attacked and how organisations make decisions about risk. There isn't one route in. That's the point.
I didn't take the route the guides describe
I'm a working security architect. I haven't got a degree. I started right at the bottom, on support and helpdesk, resetting passwords and working out why the printer on the second floor hated one particular laptop. Nobody handed me an architecture track. I got there by doing technical jobs long enough to see how the pieces connect.
So when a guide tells you step one is a degree and step two is an "entry-level security architect" job, be sceptical. In the UK organisations I've worked in and around, that job doesn't really exist. When you do see it advertised, read the duties. It's usually an engineer role with a better title, which is its own problem (I've written about that in the mid-career architect trap).
The routes that actually lead there
Every architect I respect came in from somewhere technical and stayed there long enough to get good. The starting points vary. What they share is time spent close to real systems.
- Systems and infrastructure. Support, then sysadmin or infrastructure engineer, then security engineering, then architecture. This is the one I know best. You learn how estates are actually built, patched and broken.
- Networking. Network engineer, then network security, then architecture. Segmentation, firewalls, remote access and routing are half the questions an architect gets asked. People from this route tend to be hard to bluff.
- Cloud. Cloud or platform engineer, then cloud security, then architecture. It's quicker to get noticed on this route now, but thin infrastructure knowledge shows fast.
- Identity. IAM administrator or engineer, then identity architecture, then broader security architecture. Identity touches everything, so it's a better feeder than people assume.
- Security engineering. Building and running controls, then designing them. This is the most direct route, but you still need breadth outside your own tools.
- GRC and risk. Risk or assurance roles, into risk or security architecture. This works, but only if you deliberately get technical depth along the way. Without it you'll be the person in design reviews who can't challenge an answer.
You can see these as connected routes on the security architecture pathway.
What changes when you become one
The work stops being about configuring the thing. It becomes about deciding whether the thing should exist in that shape at all.
- You need breadth. You'll review designs covering systems you've never run.
- You make design decisions other people have to build and live with.
- You think in threats and risk, not just vulnerabilities and tickets.
- You explain trade-offs to people who don't want to hear them, in plain English.
- You challenge designs, including ones from people more senior than you.
- You provide assurance, which means putting your name to a judgement.
That last one catches people out. As an engineer you can be right about your component. As an architect you're accountable for how the whole design behaves when something goes wrong.
Where people get stuck
The common stall I see is someone going deep in one tool for years, then applying for architect roles and being asked about areas they've never touched. Depth got them noticed. Breadth is what the interview tests. The fix isn't another cert. It's volunteering for the project outside your lane: the network change, the identity migration, the cloud landing zone review.
Certifications help at the end of the route more than the start. CISSP is often asked for in UK architect adverts, but it confirms breadth you already have. It won't build it for you. I've made that case in is the CISSP actually worth it.
So how long does it take?
It isn't a timetable. It's the point where you've seen enough systems fail that your judgement is worth paying for. For me that meant years of hands-on work across support, infrastructure and security before the title arrived. If someone promises you it in eighteen months from a standing start, ask them what you'll be designing, and who'll trust you to do it.
If you're still near the start, begin where I did and do it properly. Read why starting in IT support still works.