Cybersecurity Cloud Networking

Security Architect

Decide the shape of defence before anything is built — then defend the decision.

This is a senior destination, reached after several years in hands-on roles.

What you actually do

  • Design the security model for a new platform, programme or acquisition
  • Make trade-offs explicit: what this design does not protect against, and why that is acceptable
  • Set standards and reference patterns other engineers build against
  • Review proposals and turn "no" into a workable alternative
  • Translate risk into terms executives can actually decide on
  • Sequence a multi-year programme so each stage delivers something real

Technologies you may touch

Nobody uses all of these. Which ones depends entirely on the employer.

  • AWS The largest cloud platform — servers, networks, storage and identity created through an API instead of a purchase order.
  • Microsoft Azure Microsoft’s cloud — deeply tied to Windows and Entra ID identity, which is why enterprises land there.
  • Microsoft Entra ID Microsoft’s cloud identity service — sign-in, MFA and the rules deciding when access is allowed.
  • Palo Alto Networks A next-generation firewall platform built around identifying the application and user behind every flow.
  • Cisco ISE Decides who and what may join the network, and what they get access to once they do.
  • Terraform Describes cloud infrastructure in files so an entire environment can be created, reviewed and rebuilt.
  • Active Directory The Microsoft system that holds every user, group and computer account in most organisations, and decides what each can open.

Concepts you will learn

These transfer between employers and outlast any particular product.

  • Threat modelling
  • Defence in depth
  • Zero Trust architecture
  • Risk appetite
  • Reference architecture
  • Security patterns

Where this work happens

Large enterprises Government and defence Financial services Consultancies Cloud-native scale-ups

You may enjoy this if…

  • You enjoy the whole picture more than any single component
  • You like reasoning about trade-offs where every option costs something
  • You are willing to write things down and be argued with
  • You want influence over how systems are built rather than how they are run

The honest downside

A great deal of this job is meetings, documents and persuasion. You will be responsible for outcomes you do not directly control, and you will watch good designs get compromised by budget. It is reached after eight to fifteen years in hands-on roles — never before.

What it pays

Pay is the thing people most often get misled about, so here is where every number comes from — including the ones that are not really numbers.

No official category — directional only

Directional range

Roughly $140,000–$190,000

What you actually start on

Not entered directly. Eight to fifteen years of hands-on work precedes it

Outlook

+29% — much faster than average, but heavily experience-gated at the entry end

No government statistics body publishes an occupation for this role. The range shown is inferred from related occupations and industry reporting. Treat it as a rough direction, not a figure to plan around.

No BLS occupation; sits above Information Security Analysts (15-1212) and near Computer and Information Systems Managers (11-3021, $169,510 median). Any salary survey for this title is measuring people with long careers behind them — it is a destination figure, not a target.

Source: U.S. Bureau of Labor Statistics · BLS OES, May 2024 release · figures are national and United States–specific; pay varies substantially by region and employer. Nothing here is adjusted for cost of living.

CertBlueprint earns affiliate commission on some study resources. It earns nothing from Security Architect salaries, and no role is ranked, recommended or presented more favourably because of what it pays.

Where this leads

IT careers are a graph, not a ladder. These are the moves people actually make from here — each one reuses most of what you already know.

See where Security Architect sits on the whole map →

Cloud Architect

The same design discipline with a wider, less security-specific remit.

Zero Trust Engineer

Often the programme an architect is actually designing.

GRC Analyst

The governance side of the same decisions.

Often confused with

Titles overlap heavily in IT and tell you very little. Each of these puts Security Architect beside another role on the same dimensions, with the practical differences underneath.

vs Zero Trust Engineer vs Security Engineer vs Cloud Security Engineer vs Cloud Architect vs Network Security Engineer vs Identity Engineer

Try it this weekend, before you spend anything

Reading about work and doing it are different. Each of these is free, runs on the machine you already have, and takes under an hour and a half. Finding out you dislike it is a genuinely useful result — and far cheaper here than after an exam voucher.

Try the work · 60–75 minutes

Audit your own access

Free

Work out exactly what your own accounts can reach, what could take them over, and how far the damage would spread if one fell — the same exercise, at smaller scale, as securing an organisation.

Nothing to install · no account · open the steps

Before you start

Your own accounts and nobody else’s — not a partner’s, not a parent’s, not an employer’s, even with informal permission. Accessing an account that is not yours is an offence in most jurisdictions regardless of intent or relationship, and "I was learning security" has never once worked as a defence.

Uses the account settings pages you already have. Nothing to install. You will likely also improve your own security materially, which is a decent side effect.

  1. Find the account that owns all the others

    Start at your main email. Now list every service that would send a password reset there. That is not a list of accounts — it is a list of things someone gets for free the moment they take that one. Security people call this blast radius, and it is the single most useful concept in identity work.

  2. Check what is actually guarding it

    Look at the security settings of that email account. Is there a second factor? Is it SMS — which is interceptable — or an app or hardware key? Now check the recovery options: an old phone number or a disused backup address is a back door that bypasses everything else you just checked.

  3. Review what you have handed out

    Find the third-party access page on your Google, Microsoft or Apple account — the list of apps you signed in to using it. Most people have twenty to eighty entries and recognise perhaps half. Read what each was granted. Some will have read access to your entire mailbox from a service you used once in 2019.

    Any
    Google:    myaccount.google.com/permissions
    Any
    Microsoft: account.microsoft.com/privacy → apps and services
    Any
    Apple:     appleid.apple.com → Sign in with Apple

  4. Revoke, and notice how that feels

    Remove everything you do not currently use. Notice the hesitation — "what if something breaks?" That exact hesitation, multiplied across ten thousand employees and twenty years, is why organisations accumulate permissions nobody dares remove. You are feeling the central problem of identity engineering firsthand.

  5. Check the sessions still open

    Most services list active sessions and signed-in devices. Look for a device you no longer own or a location you do not recognise. Sign them all out. Note how many services do not offer this at all — that absence is itself a finding.

  6. Write the one-page assessment

    What is your most valuable account? What is the weakest path into it — is it the password, the second factor, the recovery method, or an app you granted access to years ago? What would you fix first if you had one hour? That prioritised write-up is exactly the deliverable an identity or GRC role produces, and doing it for yourself is the cheapest possible practice.

This suits you if…

  • The blast-radius idea in step one genuinely landed
  • You found at least one granted permission that alarmed you
  • You enjoyed the systematic sweep more than you expected
  • You started thinking about how this would scale to ten thousand people

If you disliked it

If this felt like fussy admin — a checklist with no puzzle in it — that is a real signal about identity, access and governance work, which is substantially careful, repetitive, high-consequence bookkeeping. People who want the adversary and the chase are usually better suited to detection, response or offensive roles, where the same rigour is applied to a moving target.

Try the work · 60–75 minutes

Design it on paper

Free

Map a real system you already own, decide what actually needs protecting, redesign it — and then be honest about what your design costs the people who have to live with it.

Nothing to install · no account · open the steps

Before you start

Map your own home network only. Everything here is pen and paper, so nothing you do can affect a system — but do not extend the exercise by surveying, probing or diagramming a network you do not own, including an employer’s, however harmless drawing it feels.

Paper and a pen. Deliberately no tools — the constraint is the point, because architecture is thinking, not diagramming software.

  1. Draw what you actually have

    Your home network, on one sheet. Router, every device, how each connects. If you did the exposure trial you already have the inventory; if not, list them from memory and then check — the gap between what you remembered and what is really there is itself the first finding, and it is the same gap every organisation has.

  2. Draw the lines nothing crosses

    Now mark what can reach what. On a normal home network the honest answer is everything reaches everything — your work laptop, your smart bulb, a guest's phone, the doorbell camera all sit in one flat space. Draw that reality, not the reality you would prefer.

  3. Name the thing that actually matters

    Of everything on that page, what would genuinely hurt to lose or have taken? Usually one or two things: the machine with your work on it, the drive with the family photos. Circle them. Everything else on the diagram exists, in security terms, mainly as a route toward those.

  4. Pick the worst device and follow it

    Choose the least trustworthy thing on the network — the cheapest smart device, the one that has not had a firmware update in three years. Trace, on the diagram, exactly what it can reach if someone takes it. That path is your blast radius, and drawing it is more persuasive than any risk score you could write down.

  5. Redesign it, on a second sheet

    Draw the version where that cannot happen. A separate network for untrusted devices. The important machine somewhere the doorbell cannot reach. Guest access that is genuinely separate. You do not have to build it — you have to be able to justify it.

  6. Now write down what your design costs

    This is the step that separates architecture from wishful thinking. What breaks? Casting to the TV probably stops working. Someone has to maintain two networks. A guest cannot print. Write the honest list, then decide which trade-offs you would actually accept and which you would not. If you cannot articulate the cost of your own design, you will lose every real architecture argument you ever have.

This suits you if…

  • Drawing the blast radius in step four was the moment it clicked
  • You enjoyed arguing with yourself about the trade-offs
  • You wanted to redraw it a third time to get it right
  • Working without tools felt freeing rather than limiting

If you disliked it

If the abstraction frustrated you and you wanted to go and actually configure something, take that seriously — architecture roles are largely diagrams, documents and persuading people, with someone else doing the building. That preference for hands-on implementation is a strength, not a deficiency, and it points at engineering rather than architecture.

Certifications that fit this path

These come last for a reason. A certification is evidence for a direction you have already chosen — it is not the direction itself.

Core ISC2 CISSP The default expectation for architecture roles, and it requires real experience. Advanced ISACA CISM For the governance and programme-leadership end. Adjacent AWS Solutions Architect Associate Architecture credibility in cloud environments. Adjacent Cisco CCDE For architects whose centre of gravity stays in network design.

Not sure whether this is actually you?

Reading about a role and enjoying the work are different things. The scenarios show you the problems instead of describing them, and tell you which ones you keep reaching for.

Try the scenarios →