Home / Managed IT / Identity & Access Security
Section D · Service 15
Attackers increasingly log in rather than break in.
Identity is now the control plane. We manage it as a security function rather than an account list — lifecycle, phishing-resistant multi-factor authentication, conditional access, privileged access, governance, and detection for when a legitimate credential starts behaving illegitimately.
Book a consultation →All managed IT servicesWhy this sits on its own page
The perimeter moved, and most controls did not follow
For two decades security architecture assumed a network boundary: inside was trusted, outside was not, and the firewall was the control that mattered. That assumption no longer holds. Applications are hosted by somebody else, staff work from anywhere, and the thing that determines whether a request is legitimate is not where it came from but whose credential is attached to it.
The practical consequence is that a stolen password, a hijacked session token or an over-permissioned service account now produces the same outcome that once required breaching a firewall — and produces it without triggering any of the controls built to detect intrusion. Nothing was exploited. Somebody simply signed in. That is why identity is treated here as its own discipline rather than a subsection of endpoint or network management.
Identity lifecycle
Entra ID, Active Directory, Google and Okta administration with joiner, mover and leaver workflows. The mover case is the one most often neglected: people change roles and accumulate permissions from every job they have held.
MFA & single sign-on
Phishing-resistant multi-factor authentication, passwordless sign-in and single sign-on federation across your SaaS applications, so access is granted once and revoked once.
Conditional access
Device, location and risk-based access policies aligned to zero trust principles — access from a compliant, known device rather than from anywhere with the right password.
Privileged access
Administrator credential vaulting, just-in-time elevation and session recording, so administrative rights are held for the duration of a task rather than permanently.
Access governance
Periodic access reviews, role design, and control of service and non-human identities — the accounts that never leave, never change password and rarely have an owner.
Identity threat detection
Detection of credential theft, token theft, privilege escalation and impossible travel, monitored continuously rather than reviewed after an incident.
Not all MFA is equal
Why we specify phishing-resistant factors
Multi-factor authentication is frequently described as a solved problem. It is not, and the distinction between factor types now decides whether the control holds against the attacks actually being run.
SMS and voice codes
Better than a password alone, and the weakest option available. Vulnerable to SIM swap, interception, and straightforward relay — the attacker asks the user for the code and the user supplies it.
App-generated codes
Stronger, and still phishable. A one-time code typed into a convincing fake page is forwarded to the real site by the attacker in real time. The user sees nothing unusual because they did authenticate.
Push approval
Convenient, and subject to fatigue attacks — repeated prompts until somebody taps approve to stop the noise. Number matching materially improves this, and is worth enabling.
Phishing-resistant factors
Hardware security keys and platform authenticators bind the credential to the legitimate domain, so a relayed request from a lookalike site simply fails. This is the tier we specify for administrative accounts.
Session tokens
Even strong authentication can be bypassed by stealing the session that follows it. Token protection, shorter lifetimes and re-authentication on sensitive actions close that gap.
Break-glass accounts
Every tenant needs emergency access that survives a failed identity provider or a misapplied policy. Those accounts are vaulted, excluded deliberately, and monitored for any use at all.
The guidance underpinning this is published rather than invented: authenticator assurance levels and the trade-offs between factor types are set out in the NIST digital identity guidelines, which is the reference we design against.
Proactive and reactive
Managing identity, and responding when one is compromised
Reduce what a stolen credential can reach
- Joiner, mover and leaver workflows executed as evidenced process, not memory
- Least-privilege role design reviewed as roles change, not only when created
- Conditional access policies tied to device compliance and risk signals
- Privileged access vaulting with just-in-time elevation and session recording
- Service and non-human identity inventory, with credential rotation
- Periodic access reviews signed off by the business rather than by IT alone
- Legacy authentication disabled, with the exceptions documented and dated
Account compromise response
- Session revocation first — a password reset alone leaves live sessions intact
- Credential reset across every place the credential was reused
- Persistence removal: inbox rules, app passwords, registered devices, added MFA methods
- Access review of what the account could reach during the exposure window
- Token and key rotation for anything the account held
- Timeline reconstruction for legal, insurer and notification decisions
The persistence step is the one most often skipped, and it is the reason compromised accounts recur. An attacker who has had access to a mailbox will frequently register their own authenticator, create an app password, or add a forwarding rule. Resetting the password without removing those leaves the door open, and the second compromise gets attributed to a weak password rather than to an incomplete first response. Where an incident needs evidentiary handling, it escalates into cyber incident response and, where required, digital forensics.
Authenticator assurance and factor guidance follows the NIST SP 800-63 Digital Identity Guidelines. Control baselines follow the CIS Critical Security Controls.
Sequence
The order this work should be done in
Identity programmes fail more often on sequencing than on tooling. Enforcing a policy before the inventory is complete locks out legitimate users and burns the organization’s willingness to continue; buying a privileged access platform before roles are understood produces an expensive vault holding the wrong credentials. The order below is the one that survives contact with a real business.
Inventory
Every identity, human and non-human, with its permissions, last sign-in and owner. Dormant accounts and orphaned service accounts are the first findings and the fastest wins, because disabling an account nobody uses breaks nothing.
Separate administration
Administrative work moves to dedicated accounts that are not used for email or browsing. This single change removes the most common path from a phished user to a compromised tenant.
Strengthen the factor
Phishing-resistant authentication for administrators first, then for staff with access to finance, payroll, customer data or the identity platform itself. Break-glass accounts are configured before enforcement, never after.
Close legacy paths
Legacy authentication protocols are identified, the applications depending on them are migrated or replaced, and the protocol is disabled. Exceptions that genuinely cannot be closed get documented, dated and compensated for.
Conditional access
Policies deployed in report-only mode, reviewed against real sign-in data, exceptions resolved, then enforced. Device compliance becomes a condition of access rather than an aspiration.
Govern continuously
Access reviews on a cycle, joiner-mover-leaver as evidenced workflow, privileged elevation just-in-time, and identity threat detection monitored. This is the steady state the earlier stages exist to make possible.
Two notes on expectations. The inventory stage almost always returns more privileged accounts than the organization believes it has, and the gap is not a sign of negligence — permissions accumulate quietly through role changes, project work and integrations that needed elevated rights once. And none of these stages is a one-time project; each produces a control that has to be maintained, which is precisely why identity belongs inside a managed service with an owner and a review cadence rather than being delivered as a fixed-scope engagement and handed back.
Questions we hear first
About identity and access
We already have MFA on everything. Are we covered?
Partly, and the gaps are usually specific: legacy authentication protocols still enabled for one application, service accounts exempted because they cannot present a factor, break-glass accounts nobody monitors, and administrators using the same account for daily work. Those exceptions are where the risk concentrates, and they are rarely visible from the admin console summary.
Won’t conditional access lock out our staff?
It can if deployed without a report-only phase. Policies are run in report-only mode first so you can see exactly who would have been blocked and why, the exceptions are resolved, and only then is enforcement turned on. Break-glass access is configured before any of it, not after.
What is a non-human identity and why does it matter?
Service accounts, API tokens, automation credentials and integration accounts. They typically hold broad permissions, never expire, are excluded from MFA by necessity and have no named owner once the person who created them moves on. They are a growing share of the identities in any environment and are often the most privileged.
Do access reviews actually find anything?
Consistently, yes — most commonly permissions accumulated through role changes, access granted for a project that ended, and accounts belonging to contractors whose engagement finished. The value is not the review itself but that removal becomes routine rather than exceptional.
How does this relate to your security operations centre?
Identity signals are among the most valuable telemetry a monitoring function receives, which is why identity threat detection feeds directly into the SOC rather than sitting in a separate console. An impossible-travel alert is only useful if somebody is watching it at the hour it fires.
Start with an identity review
An access and identity assessment typically surfaces dormant accounts, standing privileges and authentication exceptions nobody currently owns. We baseline it, then agree a remediation sequence.
Book a consultation →