Cybersecurity
The full domain, and the other capabilities within it.
Identity & Access Management
Make access something granted deliberately and removed automatically.
What this is
Identity is the control plane. Once an attacker holds a valid credential with enough privilege, most other controls become decoration. This capability covers directory and identity provider design, single sign-on, multi-factor authentication, privileged access management, and the joiner-mover-leaver process that decides whether access reflects reality.
The recurring finding is not weak passwords. It is accumulation: people change role and keep both sets of rights, service accounts outlive the system they were made for, and leavers keep access to something nobody associated with them. The fix is process supported by tooling, in that order.
When you need it
If more than one of these is true, this is usually the right place to start.
- Leavers whose access is removed by memory, department by department, rather than by a process that can be evidenced.
- Administrators using named personal accounts with permanent elevated rights, and shared passwords for the rest.
- Multi-factor authentication deployed to some applications, with the legacy ones quietly exempted.
- An access review that consists of sending managers a spreadsheet they approve without reading.
What the scope covers
- Identity architecture: directory, identity provider, federation, and which systems are authoritative for what.
- Single sign-on and multi-factor rollout, including the legacy applications that are usually the reason MFA is not universal.
- Role design: what a role grants, who may hold it, and how a request for one is approved and recorded.
- Privileged access management: credential vaulting, just-in-time elevation, and session recording for the accounts that matter most.
- Joiner-mover-leaver automation driven by the HR system, with mover treated as seriously as leaver.
What you receive
| Deliverable | What it contains |
|---|---|
| Identity architecture | Authoritative sources, trust relationships, authentication flows, and what happens to each when the identity provider is unavailable. |
| Role model | Roles, entitlements and separation-of-duty conflicts, derived from what people actually do rather than from job titles. |
| Privileged access design | Which accounts are vaulted, elevation workflow, break-glass procedure, and how break-glass use is detected and reviewed. |
| Lifecycle automation | HR-triggered provisioning and deprovisioning, with the exceptions that stay manual named and owned. |
Reference architecture
A reference, not a template. Your estate decides which parts apply and in what order they arrive.
How success is measured
Targets are agreed with you before the work starts, and reported against for its duration.
- Time from a leaver's last day to access removal, measured rather than assumed.
- Share of applications behind single sign-on with multi-factor enforced, including the legacy exemptions.
- Standing privileged accounts remaining, and the trend as just-in-time elevation replaces them.
Questions we are asked
Is multi-factor authentication enough on its own?
It removes the largest single category of account compromise and is the highest-value control here. It does not address over-privilege, dormant accounts or session theft, and push-fatigue attacks work against weaker factors. It is the first thing to do, not the only one.
Our legacy application cannot do SSO. What then?
That is the normal blocker. The options are an authentication proxy in front of it, credential vaulting so nobody handles the password directly, or compensating controls with network restriction. All three are worse than native SSO and all three are far better than an exemption nobody revisits.
How disruptive is privileged access management?
It is the change administrators resist most, because it changes their daily habits. It succeeds when the new path is genuinely quicker than the old one for routine work, so the workflow is designed with the administrators rather than issued to them.
Do we need a separate PAM product?
If you have a handful of privileged accounts and good discipline, native tooling and a documented process can be sufficient. A product earns its cost with scale, third-party access, or a requirement to record sessions — which regulated sectors increasingly have.
What about service accounts?
They are usually the worst part of the estate and the least visible: no owner, no rotation, and privileges granted for a reason nobody remembers. They are inventoried explicitly, because a role model that covers only humans leaves the easier path open.
Where do access reviews fit?
They are the control that catches what automation misses. To be worth running they need to present a reviewer with something reviewable — what this person can reach and what they have used — rather than a list of group names that gets approved wholesale.
Continue reading
Data Protection
Classification, encryption, key management and data loss prevention — starting from where your data actually is, not where the policy says it should be.
Vulnerability Management
Asset discovery, authenticated scanning, risk-based prioritisation and patch orchestration — a process that closes findings rather than counting them.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.