The enterprise security perimeter used to be easier to describe. Users worked from offices. Applications ran inside company data centres. Access often depended on whether a device was connected to the corporate network.

That model has changed. Employees now work across offices, homes and customer sites. Applications run across SaaS platforms, cloud environments and private infrastructure. Systems also connect through APIs, service accounts and automated workflows.

The number of identities has grown with the number of access paths. A user account is only one part of the picture. Applications, workloads, service accounts, devices and AI agents also need permissions.

Palo Alto Networks' Unit 42 2026 Global Incident Response Report found that identity weaknesses played a material role in nearly 90% of its investigations. The report analyses the incidents Unit 42 handled, including more than 750 major cyber incidents in 2025. This is incident-response case data, not a claim that 90% of every breach has the same cause. Read the Unit 42 report.

For security teams, the finding points to a practical priority. Identity security needs to cover every person, device and service that can reach an enterprise resource.

What does it mean when identity becomes the perimeter?

Identity is the way an organisation decides who or what can access a resource. That resource may be an application, database, cloud service, network segment or business process.

A modern access decision should consider more than the user's location. It should consider the identity, the device, the requested resource, the sensitivity of the data and the context of the request.

This approach is central to Zero Trust Architecture. NIST SP 800-207 explains that organisations should not grant implicit trust based only on network location or asset ownership. Authentication and authorisation should take place before access to an enterprise resource is established. Read NIST's Zero Trust Architecture publication.

Identity therefore connects security policy to daily access. A user may be authorised to read a file but not download it. A supplier may access one maintenance application for a limited period. A service account may call a specific API but should not have administrator rights across the environment.

How attackers exploit identity weaknesses

Attackers often prefer valid credentials to a noisy attempt to break through a perimeter. Stolen credentials and session tokens can help them enter through normal access paths. Excessive permissions can then help them reach more systems.

Several weaknesses make this easier.

Stolen credentials and session tokens

Phishing, password reuse and compromised devices can expose credentials. Attackers may also steal session tokens or abuse existing browser sessions. A valid session can make suspicious activity harder to distinguish from normal work.

Multi-factor authentication reduces the risk of password-only access. Phishing-resistant methods offer stronger protection for privileged and high-risk users. Session controls and device checks also matter.

Excessive permissions

Users often keep access after changing roles. Contractors may retain accounts after a project ends. Service accounts may accumulate permissions as applications change.

These permissions create paths that attackers can use after obtaining initial access. Regular access reviews should identify accounts with more privileges than their roles require.

Unmanaged service and machine identities

Applications use service accounts, API keys, certificates and tokens to communicate. Devices and workloads also authenticate to other systems. These identities may not receive the same review as employee accounts.

A machine identity should have an owner, purpose, expiry or rotation plan, and limited permissions. Credentials should not be stored in scripts or shared across unrelated services.

Fragmented identity systems

An organisation may have several directories, cloud identity providers and SaaS platforms. Different teams may manage identities in separate ways. This creates gaps in visibility and makes it harder to remove access consistently.

A consolidated view does not always require one technical directory. It does require clear ownership, reliable integration and central reporting across identity stores.

Weak third-party access

Suppliers, partners and support teams may need access to business systems. Long-lived accounts and broad remote access can create risks beyond the organisation's direct control.

Use named supplier identities, approval windows and access limits. Review activity and remove access when the work ends.

The identity controls every enterprise should review

A strong identity programme combines policy, technology and operating discipline. The following controls provide a practical baseline.

1. Build an identity inventory

Identify human users, administrators, contractors, service accounts, application identities, devices and workloads. Record an owner and business purpose for each. Include cloud and SaaS environments, not only the corporate directory.

2. Strengthen authentication

Use multi-factor authentication for users and stronger methods for privileged accounts. Consider phishing-resistant authentication for administrators and high-risk roles. Set clear rules for legacy authentication and emergency access.

3. Apply conditional access

Use context to decide whether a request should be allowed. Relevant signals may include device health, user risk, location, application sensitivity and unusual behaviour. A high-risk request may require additional verification or block access.

4. Enforce least privilege

Give users and services only the permissions required for their tasks. Separate everyday accounts from administrative accounts. Use time-limited access for sensitive work where possible.

5. Manage privileged access

Identify accounts that can change systems, data or security policy. Require additional controls for their use. Use privileged access management or just-in-time access where appropriate. Record and review privileged sessions.

6. Review identity throughout its lifecycle

Access should change when a person joins, moves roles or leaves. Supplier accounts should have an end date. Application permissions should be reviewed when the workflow changes.

Automate routine provisioning and deprovisioning where possible. Keep an exception process for urgent operational needs, but assign an owner and review date to every exception.

7. Secure machine identities

Give each service or workload a distinct identity. Use short-lived credentials where supported. Rotate secrets and certificates. Store secrets in an approved vault rather than in source code or local configuration files.

8. Monitor identity activity

Collect authentication events, privilege changes, access denials and unusual session activity. Look for patterns such as impossible travel, unexpected access to sensitive resources and new privileges outside approved change windows.

Connect identity events with endpoint, network, cloud and application data. This helps security teams understand what happened after an account was compromised.

Connect identity to network and data controls

Identity policy is more effective when it works with network segmentation and data protection. A user should not gain access to every system simply because authentication succeeded.

Network segmentation can limit the routes available between systems. Application access policies can restrict which services a user or workload may reach. Data controls can limit what an authorised user can view, copy or share.

Arche's Networks practice describes Zero Trust Network Architecture capabilities, including segmentation, identity-based access, micro-segmentation and Zero Trust Network Access. Its Cybersecurity practice covers broader security services, while Data Security addresses data discovery, encryption, access controls and leakage prevention.

How to strengthen identity security in 90 days

A full identity programme may take longer. A focused first 90 days can still address high-risk gaps.

Days 1 to 30: find the identities. Build a list of privileged users, service accounts, third-party accounts and critical applications. Identify shared accounts and accounts without owners. Review the most sensitive systems first.

Days 31 to 60: reduce immediate exposure. Enforce stronger authentication for privileged users. Remove stale accounts. Restrict supplier access. Reduce excessive permissions on critical systems. Confirm that emergency accounts are protected and monitored.

Days 61 to 90: improve review and detection. Set access review cycles for critical applications. Establish owners for service identities. Connect identity logs to security monitoring. Create response steps for a suspected account or token compromise.

At the end of the period, review what has changed. Track the number of privileged accounts, stale identities, orphaned service accounts and high-risk access exceptions. Measure how quickly the team can disable a compromised identity.

Questions to ask when evaluating identity security solutions

Before selecting a platform or service, ask:

·       Can it identify human and non-human identities across cloud, on-premises and SaaS systems?

·       Can it show who owns each service account, token or application identity?

·       Does it support phishing-resistant authentication for privileged users?

·       Can it enforce least privilege and time-limited access?

·       Does it integrate with the organisation's existing identity providers?

·       Can access reviews include business owners and application owners?

·       Are privileged actions and changes recorded?

·       Can identity events be correlated with endpoint, network and cloud activity?

·       How does the platform handle supplier access and emergency accounts?

·       Can the organisation export identity data and audit records if it changes providers?

Ask the provider to demonstrate the controls with your actual applications and user roles. A feature list does not show whether the solution fits the organisation's access model.

What role does a Managed SOC play?

Identity controls reduce the opportunities attackers can exploit. Monitoring helps teams detect when those controls are being misused or bypassed.

A security operations team can review suspicious logins, unusual privilege changes and access patterns. It can also correlate identity events with activity on endpoints, networks and cloud services.

Arche's Managed SOC describes 24/7 security monitoring, threat analysis and incident response. This can support organisations that need ongoing review of security events across their IT environment.

The airport cybersecurity case study shows how access control, network monitoring and segmentation can work together in a large, multi-system environment.

Frequently asked questions

Is identity security the same as identity and access management?

Identity and access management is a core part of identity security. Identity security also covers machine identities, privileged access, threat detection, access governance and response to compromised accounts.

Does multi-factor authentication solve identity risk?

No. It reduces the risk of password-only access, but it does not remove excessive permissions, stale accounts, stolen sessions or weak service identities. It should be part of a wider control model.

What is a machine identity?

A machine identity allows an application, device, workload or service to authenticate to another system. Examples include certificates, API credentials and service accounts.

How does identity support Zero Trust?

Identity helps determine who or what is requesting access. Zero Trust also considers the device, resource, context and policy before granting access. It does not treat network location as proof of trust.

Put identity at the centre of access decisions

Every enterprise should know which identities can reach its critical resources. It should know who owns those identities and why they have access.

Start with privileged accounts, third-party access and service identities. Reduce permissions that no longer serve a business need. Then connect identity monitoring with the rest of the security programme.

Explore Arche's cybersecurity services, review its Zero Trust network capabilities, or contact the team to discuss your access requirements.