Identity-first security for UK IT leaders

Users access work applications from home, hotels and coffee shops. Applications run in AWS, Azure and SaaS platforms outside the corporate network. Access controls need to account for those connections.

An identity-first security strategy checks who is requesting access and what they are allowed to do, alongside where they are connecting from.

This guide covers the core components of an identity-first security programme, from IAM and MFA to privileged access management and access governance, with practical steps for UK IT leaders.

---

Why network location is not enough

The traditional security model assumed a clear boundary between "inside" (trusted) and "outside" (untrusted). Firewalls, intrusion detection systems, and network segmentation were designed to defend that boundary.

Three changes expose the limits of that model:

1. The workforce went everywhere. Remote work, hybrid arrangements, and mobile devices mean users access corporate resources from networks you do not control. A connection from an internal network is not sufficient evidence of a trustworthy user or device.

2. Applications moved to the cloud. SaaS adoption means your critical business applications, including CRM, HR, finance and collaboration tools, live outside your network. The data you are trying to protect is not inside your perimeter.

3. Attackers learned to steal credentials. Stolen passwords let attackers attempt to use legitimate access routes. Assess credential theft alongside other routes into your own environment; an unscoped industry percentage is not a substitute for that assessment.

As I explore in the Cyber Resilience series, modern security strategy must assume the network is already compromised and focus on what attackers actually target: identities.

The core concept: identity first security

Identity First Security shifts the focus from "Where are you coming from?" (network) to "Who are you and what are you allowed to do?" (identity).

A stolen credential can let an attacker impersonate an account. Network segmentation, endpoint controls, device checks and resource-level authorisation can still limit what that account reaches. Identity protection complements those controls.

The strategic implication is clear: investment should follow risk. If identity compromise is your primary threat vector, identity protection should be your primary investment. For organisations that need hands-on support turning that principle into a roadmap, my IT compliance services help bridge policy, controls, and delivery.

Identity-first security changes how organisations make and review access decisions.

---

Five areas of identity security

Review five connected areas of identity security. A weakness in one can undermine controls in the others.

Authentication: proving identity

Authentication answers the question: "Are you who you claim to be?" The strength of your authentication directly determines your exposure to credential-based attacks.

The authentication spectrum

Authentication methods provide different protection. Compare them against the risk of the access they permit:

Authentication assurance depends on the whole implementation. A biometric alone is not an authenticator, and an attestation check does not create a universal "maximum security" level.

Multi-factor authentication: getting it right

Require appropriate MFA for supported human access to sensitive and privileged systems. Define separate controls for workload identities and intentionally public endpoints. Implementation and recovery details matter.

The MFA fatigue problem. Repeated unexpected prompts can lead a user to approve an attacker's request. Mitigations include:

• Number matching (user must enter a code shown on the login screen)
• Location and risk context display
• Rate limiting on authentication attempts
• Anomaly detection on approval patterns

The SMS vulnerability. In a SIM swapping attack, attackers convince a mobile carrier to transfer a phone number. This can defeat SMS-based MFA. High-value targets (executives, IT administrators, finance personnel) should never rely on SMS for authentication.

The enrolment challenge. MFA that users cannot set up is MFA that does not get deployed. Invest in clear onboarding processes, help desk training, and self-service recovery options. The goal is 100% coverage, not just 100% mandate.

The passwordless future

Password reuse, phishing and insecure recovery can undermine authentication. Passkeys can reduce dependence on passwords, but deployment and recovery still need controls.

Passkeys use public-key credentials associated with a relying party. WebAuthn binds their use to the site, which provides phishing resistance. Some passkeys stay on a device; others synchronise through a credential provider, so their private keys are exportable under that provider's protection. A PIN or biometric can activate the credential. Neither passkeys nor biometrics make a compromised endpoint or stolen session harmless. See NIST's authentication guidance for phishing resistance, syncable authenticators and assurance requirements.

Benefits of passwordless:

• Phishing resistance. Site binding prevents the credential from authenticating to an impostor site in the way a typed password can.
• Better user experience. No passwords to remember or type.
• Potential reduction in password resets. Measure this alongside device-recovery and enrolment support.
• A stronger authentication option. Check the selected method against the assurance level and recovery requirements you must meet.

Passwordless implementation considerations:

• Platform support (Windows Hello, Apple Touch/Face ID, Android biometrics)
• Recovery mechanisms when devices are lost
• Backup authentication for shared devices
• Legacy application compatibility

Pilot passwordless access with representative users and recovery scenarios. Choose the schedule from application support, device management and the assurance required.

Authorisation: controlling access

Authentication proves identity. Authorisation determines what that identity can do. Poor authorisation leads to over-privileged users, the primary enabler of lateral movement and privilege escalation attacks.

The principle of least privilege

Users should have the minimum access necessary to perform their job function. This principle is simple to state and difficult to implement.

Why least privilege fails in practice:

• Access accumulates over time as roles change
• Managers approve requests without understanding implications
• "Just in case" access persists indefinitely
• System complexity obscures actual permissions
• No regular review or recertification process

Implementing effective least privilege:

1. Role-based access control (RBAC). Define standard roles aligned to job functions. Users receive role membership, not individual permissions.

2. Access certification. Regular (quarterly or semi-annual) reviews where managers certify that their team members still need their current access.

3. Access analytics. Flag unused permissions for owner review. Revoke them through a controlled process after checking emergency and service dependencies.

4. Segregation of duties. Ensure conflicting permissions (e.g., creating vendors and approving payments) cannot exist in the same identity.

Just-in-time access: reducing standing privilege

Review whether administrators need permanent elevated access or can activate it for a bounded task.

Just-In-Time (JIT) access grants elevated privileges only when needed, for a specific duration, with specific approval. Configure and test expiry or revocation, including the behaviour of existing sessions and tokens. Ending a task does not necessarily terminate its elevated session.

JIT implementation approaches:

• Privileged Access Management (PAM) tools. Solutions like CyberArk, BeyondTrust, or Delinea provide JIT access with session recording and approval workflows.

• Time-limited cloud roles. Microsoft Entra Privileged Identity Management supports eligible assignments and controlled activation, subject to licensing and configuration. Permission-analysis tools are not interchangeable with a JIT activation service.

• Service account governance. Non-human identities (service accounts, API keys) also benefit from JIT principles. Rotate credentials frequently and limit scope.

Federation: centralising identity

Single Sign-On (SSO) is also a security control. It creates a single point for access control and a single point for logging and auditing.

The security benefits of federation

Centralised enforcement. Federation can apply shared authentication policy to integrated applications. Verify each integration and document local-login, service-account and session exceptions.

Offboarding. Disabling the central account can stop new federated sign-ins, but existing sessions, tokens, local accounts and API credentials may remain. Test deprovisioning and revocation in each important application and retain evidence of the result.

Visibility. The identity provider records the events it handles. Collect application and provisioning logs as well; unmanaged or local accounts do not become visible merely because other users use SSO.

Reduced credential sprawl. Fewer passwords means fewer opportunities for password reuse, phishing, and credential stuffing attacks.

SSO implementation strategy

Phase 1: Core applications. Start with the applications everyone uses, such as email, collaboration and file storage. Users can become familiar with SSO through those applications.

Phase 2: Business-critical systems. Extend to CRM, ERP, HR systems, and finance applications. These contain sensitive data and require strong access governance.

Phase 3: Long tail applications. Address the dozens or hundreds of departmental SaaS tools. This is where shadow IT becomes visible.

Phase 4: Legacy applications. Use identity-aware proxies or SAML/OIDC gateways to bring legacy systems into your identity system.

SSO does not mean SSO-only. Federation centralises authentication but should not weaken it. Federated applications should still require MFA through your identity provider, and high-sensitivity applications may require step-up authentication.

Governance: managing the lifecycle

Identity Governance and Administration (IGA) manages onboarding, role changes and offboarding for identities.

The identity lifecycle

Access certification programmes

Regular access reviews are essential but often implemented poorly. Managers rubber-stamp certifications without reviewing, creating compliance theatre rather than actual security.

Effective certification design:

• Risk-based scope. Focus reviews on sensitive applications and elevated privileges. Not every application needs quarterly certification.

• Meaningful information. Provide managers with context: What does this access allow? When was it last used? Who else has this access?

• Reasonable volume. If managers face hundreds of certifications, they will rubber-stamp. Keep certification campaigns manageable.

• Consequence for non-response. Escalate overdue reviews and apply an agreed revocation policy. Check service dependencies and emergency access before removing accounts automatically.

• Continuous certification. Supplement periodic campaigns with continuous monitoring and triggered reviews when anomalies occur.

Visibility: detecting and responding

Identity systems generate rich telemetry about user behaviour. This data is essential for detecting compromised accounts and insider threats.

Identity-based detection

Traditional security monitoring focuses on network traffic and endpoint behaviour. Identity-based detection adds identity context:

Impossible travel. Distant sign-ins close together are a signal to investigate. VPNs, proxies, mobile routing and location errors can produce false positives. Correlate the event with device, session and user evidence before concluding compromise.

Anomalous access patterns. A marketing user suddenly accessing source code repositories suggests compromised credentials or insider threat.

Authentication anomalies. Spike in failed authentications, successful authentication from a new device or location, authentication at unusual times.

Privilege escalation. Unexpected changes to group membership or role assignments.

Security information integration

Identity telemetry should flow to your security operations:

• Forward authentication logs to your SIEM
• Integrate with SOAR for automated response
• Include identity context in threat hunting
• Correlate identity events with endpoint and network data

The goal is a unified view where identity is one dimension of your security monitoring, not a siloed system.

---

The identity security maturity model

Not every organisation starts from the same place. Understanding your current maturity helps prioritise investments and set realistic expectations.

This is an author-proposed planning model, not a benchmark or certification scheme. Choose improvements from your risks and operating constraints; more automation does not automatically mean better security.

---

Identity security assessment checklist

Use this checklist to evaluate your current identity security posture:

Authentication assessment

• Interactive external access has appropriate MFA; workload and emergency access have separately documented controls
• Phishing-resistant MFA (FIDO2/passkeys) available for all users
• Phishing-resistant MFA mandatory for privileged accounts
• MFA fatigue protections in place (number matching, rate limiting)
• SMS-based MFA eliminated for high-value accounts
• Passwordless authentication available and promoted
• Password policies enforce length over complexity
• Breached password detection enabled
• Self-service MFA recovery does not create bypass vulnerability
• Guest and contractor authentication follows same standards

Authorisation assessment

• Role-based access control implemented for major systems
• Standard roles defined and documented
• No shared accounts for production access
• Privileged access requires approval and is time-limited
• Just-in-time access implemented for administrative privileges
• Service accounts have documented owners
• Service account credentials rotate regularly
• API keys and secrets managed centrally
• Segregation of duties enforced for sensitive functions
• Emergency access (break-glass) procedures documented and monitored

Federation assessment

• SSO implemented for all supported applications
• SSO applications catalogue maintained
• Non-federated applications tracked and justified
• Conditional access policies enforce security requirements
• Session timeouts appropriate for sensitivity
• Federation trust relationships reviewed periodically
• External identity federation (B2B) follows security standards
• Consumer identity (B2C) segregated from corporate

Governance assessment

• Automated provisioning for major systems
• Deprovisioning occurs at the agreed departure time, with urgent revocation for higher-risk departures
• Access certification conducted at least annually
• Access certification includes usage information
• Orphaned accounts identified and removed
• Role explosion controlled (not too many roles)
• Access request workflows exist with approval
• Segregation of duties violations prevented or detected
• Identity governance reporting available to stakeholders
• Compliance reporting automated

Visibility assessment

• Authentication events logged centrally
• Authorisation events logged centrally
• Administrative actions logged and monitored
• Impossible travel detection enabled
• Anomalous access behaviour alerting configured
• Failed authentication monitoring and response
• Privilege escalation alerting enabled
• Identity events integrated with SIEM
• Incident response playbooks include identity scenarios
• Identity forensics capability exists

---

The identity tool landscape

Identity security products have overlapping capabilities. Compare the categories when selecting vendors and designing integrations.

Compare the specific licensed features and integrations, not just the vendor name. Consolidation can reduce administration but may leave coverage gaps that need another control.

Build versus buy considerations. For most organisations, buying is the right answer. Identity has established products, and their implementation is the focus here. Custom identity systems create technical debt and security risk.

---

Implementation roadmap: 90 days to identity first security

This 90-day roadmap is an illustrative planning structure. Scope the work to your estate and capacity rather than treating every listed capability as a guaranteed deliverable.

Phase 1: foundation (days 1-30)

The first month establishes understanding and addresses critical gaps.

Week 1: assessment and quick wins

Objectives:

• Understand current identity security posture
• Identify and address critical vulnerabilities
• Establish executive sponsorship

Activities:

• Complete the Identity Security Assessment Checklist
• Identify systems without MFA and create remediation plan
• Audit privileged accounts and eliminate unnecessary standing privilege
• Review recent offboarding and confirm access was revoked
• Brief leadership on findings and roadmap

Quick wins to implement:

• Enable MFA for any remaining gaps
• Review inactive accounts with their owners, then disable access through a controlled process
• Establish protected, monitored emergency access with tested recovery procedures
• Enable breach password detection

Deliverables:

• Assessment scorecard
• Critical gaps prioritised
• Executive sponsor confirmed

Week 2: architecture and vendor strategy

Objectives:

• Define target identity architecture
• Evaluate vendor landscape
• Plan integration approach

Activities:

• Map current identity tools and capabilities
• Identify architectural gaps
• Evaluate vendor options for gaps
• Plan phased implementation approach
• Assess cloud identity posture (Azure AD, AWS IAM, GCP IAM)

Deliverables:

• Current state architecture diagram
• Target state architecture diagram
• Vendor shortlist with evaluation criteria

Week 3: policy and process foundation

Objectives:

• Establish identity security policies
• Define governance processes
• Create operational procedures

Policy development:

• Authentication policy (MFA requirements, password standards)
• Authorisation policy (least privilege, approval requirements)
• Access certification policy (frequency, scope, consequences)
• Privileged access policy (JIT requirements, monitoring)
• Incident response procedures for identity compromise

Process establishment:

• Access request workflow
• Certification process
• Privileged access request process
• Offboarding checklist

Deliverables:

• Policy documents drafted
• Process workflows documented
• RACI matrix for identity operations

Week 4: critical controls implementation

Objectives:

• Implement highest-priority controls
• Establish monitoring baseline
• Prepare for Phase 2

Implementation activities:

• Deploy phishing-resistant MFA for all privileged accounts
• Enable conditional access for high-risk scenarios
• Configure authentication logging and alerting
• Implement privileged session monitoring
• Establish access review process for privileged accounts

Deliverables:

• Privileged account MFA at 100%
• Monitoring baseline established
• Phase 2 plan approved

Phase 1 checkpoint

Before proceeding, confirm:

• Assessment complete with prioritised gaps
• Executive sponsorship confirmed
• Target architecture defined
• Policies drafted and reviewed
• MFA gaps closed
• Privileged access controls enhanced
• Monitoring and alerting operational
• Phase 2 resourced and approved

Phase 2: capability building (days 31-60)

The second month builds core identity capabilities.

Week 5: SSO expansion

Objectives:

• Extend SSO coverage
• Eliminate password sprawl
• Improve visibility

Activities:

• Inventory all applications and current SSO status
• Prioritise applications for SSO integration
• Configure SSO for priority applications
• Establish process for new application SSO requirements
• Track and justify non-federated applications

Deliverables:

• Application inventory with SSO status
• SSO coverage increased by target percentage
• Non-federated application exceptions documented

Week 6: access governance implementation

Objectives:

• Implement access certification
• Establish lifecycle automation
• Address access accumulation

Activities:

• Configure IGA platform (or manual process if no platform)
• Define certification campaigns and scope
• Launch initial certification for high-risk applications
• Implement automated provisioning for core systems
• Implement automated deprovisioning on termination

Deliverables:

• First certification campaign launched
• Automated provisioning operational
• Automated deprovisioning verified

Week 7: privileged access programme

Objectives:

• Implement JIT access for privileged operations
• Establish privileged account governance
• Enable session monitoring

Activities:

• Identify all privileged access paths
• Configure JIT access for administrative accounts
• Implement session recording for privileged sessions
• Establish privileged access review process
• Deploy break-glass procedures with monitoring

Deliverables:

• JIT access operational for administrative accounts
• Session recording enabled
• Privileged access governance process active

Week 8: identity threat detection

Objectives:

• Implement identity-based threat detection
• Integrate with security operations
• Establish response procedures

Activities:

• Configure identity threat detection (native or ITDR tool)
• Enable impossible travel detection
• Configure anomalous access alerting
• Integrate identity events with SIEM
• Develop identity incident response playbooks

Deliverables:

• Identity threat detection operational
• SIEM integration complete
• Playbooks documented and tested

Phase 2 checkpoint

Before Phase 3, confirm:

• SSO coverage significantly expanded
• Access certification launched
• Automated provisioning and deprovisioning working
• JIT access implemented for privileged accounts
• Session monitoring active
• Identity threat detection operational
• SIEM integration complete
• Response playbooks documented

Phase 3: maturity and optimisation (days 61-90)

The final month establishes sustainable operations and advances towards maturity.

Week 9: passwordless acceleration

Objectives:

• Expand passwordless adoption
• Reduce password dependency
• Improve user experience

Activities:

• Enable passkey registration for all users
• Launch passwordless pilot with willing departments
• Communicate benefits and provide user guidance
• Track adoption metrics
• Address enrollment friction

Deliverables:

• Passkey registration available organisation-wide
• Pilot departments using passwordless
• Adoption tracking in place

Week 10: governance optimisation

Objectives:

• Refine access governance based on experience
• Address certification feedback
• Expand automation

Activities:

• Review first certification cycle results
• Address manager feedback on process
• Implement access analytics for unused permissions
• Expand automated provisioning coverage
• Implement continuous certification triggers

Deliverables:

• Certification process refined
• Unused access identified and actioned
• Automation expanded

Week 11: security operations integration

Objectives:

• Fully integrate identity into security operations
• Establish metrics and reporting
• Enable continuous improvement

Activities:

• Validate identity detection and response integration
• Establish identity security metrics dashboard
• Create executive reporting
• Conduct identity incident simulation
• Document lessons learned and improvement areas

Deliverables:

• Security operations fully integrated
• Metrics dashboard operational
• Executive reporting established

Week 12: steady state and future planning

Objectives:

• Transition to operational mode
• Plan continued maturity improvement
• Establish ongoing governance

Activities:

• Complete operational handover
• Establish ongoing review cadence
• Plan Phase 4 initiatives (advanced capabilities)
• Document programme outcomes
• Brief leadership on progress and future roadmap

Deliverables:

• Operational handover complete
• Phase 4 roadmap drafted
• Programme outcomes documented

Phase 3 checkpoint

At day 90, assess:

• Passwordless adoption growing
• Access governance operating smoothly
• Identity integrated into security operations
• Metrics demonstrating improvement
• Operational ownership clear
• Future roadmap defined
• Leadership briefed on outcomes

---

Verify offboarding with a complete example

For a hypothetical departing finance user, disabling the identity-provider account is the first step. The owner should also revoke supported sessions, remove local access in the finance application, review delegated mailbox access and rotate any shared credentials the person knew. Confirm that scheduled business jobs have a suitable service identity before removing a dependency.

Retain evidence that the user can no longer sign in or use an existing session in the important applications. Record exceptions and their resolution dates. This tests the result rather than merely proving that an administrator clicked Disable.

Integration with zero trust architecture

Identity First Security is the foundation of Zero Trust Architecture. You cannot implement Zero Trust without robust identity capabilities.

The Zero Trust principle of "never trust, always verify" requires:

• Strong authentication. You must prove identity before any access decision.
• Continuous verification. Identity validation is not a one-time event but continuous throughout the session.
• Least privilege. Access is granted to specific resources, not network segments.
• Context awareness. Access decisions consider identity, device, location, and behaviour.

Zero trust depends on reliable identity controls. The identity programme described in this article creates the foundation that Zero Trust requires.

---

Common pitfalls and how to avoid them

Pitfall 1: MFA theatre

The problem: Deploying MFA for compliance checkboxes while allowing weak methods and bypass mechanisms that attackers easily defeat.

The solution: Treat MFA as a security control, not a compliance requirement. Measure actual security improvement (phishing-resistant methods, bypass elimination) rather than deployment percentage.

Pitfall 2: access reviews without enforcement

The problem: Access certification that managers rubber-stamp without reviewing. No consequences for unapproved access.

The solution: Give reviewers context and an escalation deadline. Apply an agreed revocation policy that accounts for service and emergency dependencies. Track repeated overdue reviews.

Pitfall 3: ignoring non-human identities

The problem: Focus on user accounts while service accounts, API keys, and workload identities proliferate unmanaged.

The solution: Include non-human identities in your governance programme. Document owners, rotate credentials, apply least privilege. Review the permissions of each workload identity against the task it performs.

Pitfall 4: tool sprawl

The problem: Deploying multiple overlapping identity tools that do not integrate, creating gaps and complexity.

The solution: Define a coherent identity architecture. Evaluate tools for integration capability. Consider platform consolidation where it makes sense.

Pitfall 5: forgetting the user experience

The problem: Security controls so burdensome that users find workarounds or productivity suffers.

The solution: Test enrolment, routine sign-in and recovery with representative users. Measure support effort and failed access as well as security coverage.

---

Measuring identity security effectiveness

Key metrics

The percentages below are example internal targets, not industry requirements. Set them against the systems in scope and review exceptions individually. Departing users should lose access at the agreed termination time; a target measured in hours is not permission to retain access unnecessarily.

Executive reporting

Different stakeholders need different views:

For the Board: Risk reduction metrics, compliance status, benchmark comparisons.

For the CISO: Operational effectiveness, threat detection performance, programme maturity.

For IT Leadership: Operational efficiency, user experience, integration status.

For Business Units: Access enablement, friction reduction, support responsiveness.

---

Final thoughts

Review access controls across remote users and cloud applications, including how they respond to stolen credentials.

Use identity checks to control access to those resources.

Plan the work in stages:

• Prioritise MFA gaps, with a tested deployment and recovery plan
• Implement phishing-resistant authentication for privileged users this quarter
• Establish access governance and certification this half
• Deploy JIT access and identity threat detection this year
• Move towards passwordless progressively

Review identity controls alongside network and endpoint controls.

Allocate funding from the gaps and consequences you have identified. The relative price of network and identity tools does not establish the right investment balance.

---

Implementing your identity first security programme

Building a mature identity security programme requires strategic planning, technical expertise, and organisational change management. My security consulting services and IT compliance services help organisations assess their current posture, design target architectures, and implement identity programmes that reduce risk while improving user experience. For broader technology alignment, my IT management services ensure identity strategy integrates with your wider IT roadmap.

Get in touch to discuss how to strengthen your identity security posture.

---

Related reading: Zero Trust: It's Not a Product, It's a Strategy | Cyber Resilience 2026 | MSSP UK services buyer guide