People ask me what a security architect actually does, usually because they are trying to work out whether they need one or whether the person they already have covers it. It is a fair question. The title is used loosely, and the work is easy to confuse with three other jobs that sit next to it.
Here is the honest version, and the signals that tell you it is time to bring one in.
The job is decisions, not configuration
An engineer builds what has been decided. An analyst investigates what has happened. A consultant advises on a defined question. An architect decides what the environment should look like, in what order it should get there, and what the organization is choosing not to do.
That means most of my output is not configuration. It is a set of decisions with reasoning attached. Which identity model the tenant runs on. Where the data boundary sits. What gets logged, for how long, and who is expected to act on it. Which risks are accepted on purpose rather than by accident.
The configuration follows from that, and it usually follows quickly once the decisions are clean. The slow, expensive part is making decisions in the wrong order, then rebuilding around them.
Why the order matters more than the tooling
A Microsoft environment has an unusual property: almost everything hangs off identity. Conditional Access, Defender, Purview, Intune and the rest all assume identity is already coherent. If it is not, every layer above it inherits the mess.
So a large part of the work is sequencing. Identity first, then device posture, then data, then detection, then the governance that keeps it from drifting back. Teams that start with a product rollout instead of a sequence end up with tools that are technically deployed and practically ignored.
This is also why buying a higher license tier rarely changes much on its own. The tier gives you capability. The architecture decides whether any of it does useful work.
When you actually need one
You probably need an architect when one of these is true:
- Nobody can explain why access is configured the way it is, only how
- Two teams are making conflicting decisions about the same tenant
- A migration, merger or tenant consolidation is coming and there is no target state
- An audit is approaching and the answers depend on who you ask
- Copilot or another AI rollout is on the table and nobody owns the data readiness question
- You are about to spend a significant amount on licensing and cannot say what it buys you
The common thread is that the problem is a decision problem, not a task problem. If the work is well defined and somebody just needs to do it, you need engineering capacity, not architecture.
When you do not
If the environment is small, stable and already documented, an architect is an expensive way to get a checklist. A good assessment and a clear baseline will serve you better and cost far less.
If the real issue is that nobody is watching the alerts, the answer is an operations capability, not a new design. Architecture does not fix an empty chair.
I would rather say that plainly than sell a roadmap to someone who needs two weeks of focused engineering.
What good looks like afterwards
The test I use is simple. Six months after the work, can somebody who was not in the room explain why the environment is built the way it is, and act on the roadmap without me. If the answer is no, the architecture lived in my head rather than in the organization, and that is a failure regardless of how good the design was.
That is the actual job. Not choosing products. Making the decisions that products end up expressing, writing them down in a form a team can run, and being honest about the ones that were traded away.