Security teams invest heavily in artificial intelligence, data protection and sophisticated detection capabilities. Yet one of the most consequential parts of the environment is often treated as foundational plumbing: the identity infrastructure responsible for determining who can access critical resources and what they can do.
Weak identity security architecture does not merely leave a theoretical gap. It can create a ready-made route through the organisation for an attacker who gains a foothold.
The uncomfortable reality is that attackers do not always need to invent a new attack path. In environments with standing administrative access, overprivileged roles, weak authentication controls and limited governance, the path may already have been designed for them.
TL;DR
Most attackers do not need to create a path to administrative control because existing identity architectures often provide one. By combining Microsoft Entra PIM, phishing-resistant authentication, Conditional Access, device compliance and continuous identity governance, organisations can significantly reduce the risk of privilege escalation and identity-based attacks.
Attackers Follow the Path You Designed
When an organisation is compromised, attention naturally turns to the initial access method. Teams may investigate adversary-in-the-middle phishing, VPN attacks, lateral movement or compromise through a third-party IT provider. These are all important questions, but initial access is only the beginning of the story.
Once a foothold exists, the attacker looks for the easiest path to valuable systems, sensitive information and administrative control. If the identity environment provides persistent privilege without meaningful guardrails, the attacker’s next move becomes considerably easier.
Imagine an environment in which a privileged user has standing administrative access but lacks controls such as least privilege, just-in-time access, multiple administrative approvals and scoped administration. The attacker does not need to build this pathway. They only need to exploit it. A compromised user account should not automatically provide a direct path to broad administrative control. The architecture should introduce deliberate barriers that limit movement, require stronger verification and reduce the duration of elevated access.
Convenience Can Become a Security Weakness
Many identity risks develop gradually. A temporary administrative assignment becomes permanent. A Global Administrator account is used because configuring a narrower role takes more time. An administrator uses the same identity for email, SharePoint and privileged operations because maintaining separate accounts feels inconvenient.
Each decision may appear reasonable in isolation. Together, they can form an exceptionally attractive route for an adversary.
Several recurring weaknesses:
- No practical application of Zero Trust principles
- No separation between standard and administrative identities
- Standing administrative access
- Multiple roles elevated simultaneously
- Global Administrator used for routine administrative work
- Privileged identities embedded in services
- Device-compliance signals excluded from access decisions
- Inadequate identity governance
Zero Trust requires organisations to verify explicitly, use least privilege and assume breach. This also connects privileged identity design with Australian Information Security Manual (ISM) controls covering dedicated privileged accounts, restrictions on privileged access to internet-facing services and limiting access to what users and services require for their duties.
These principles matter because administrative convenience has a cumulative effect. Every unnecessary role, long-lived assignment and unmanaged administrative device increases the available attack surface.
Separate Daily Work from Privileged Administration
A user’s everyday identity commonly has access to email, collaboration platforms, files and business applications. It is therefore exposed to links, attachments, shared content and routine interactions with internal and external parties.
Assigning privileged roles to that same identity combines two very different risk profiles.
- A standard account is used for daily activities such as email, Microsoft 365, SharePoint and business applications.
- A dedicated administrative account is used only when privileged actions are required.
- The administrative identity is cloud-native, does not require a standard user licence and is monitored.
- Privileged roles are assigned to the administrative identity using appropriate role-based access controls.
Separation does not eliminate identity risk, but it reduces unnecessary exposure. A phishing email received by the standard account should not directly expose the identity used for sensitive administrative operations.
Organisations should also consider whether cloud administrative identities need to remain connected to on-premises identity infrastructure. Separating the source of authority (SoA) for cloud and on-premises administrative identities, including using an in-cloud account for cloud role assignments rather than continuing to depend on a synchronised administrative account.
Replace Standing Privilege with Just-in-Time Access
Creating separate accounts is only one layer. A dedicated administrative account with permanent roles remains a standing target.
A more defensible model is to make privileged access:
- Eligible rather than permanently active
- Time-bound rather than indefinite
- Justified before use
- Approved when the risk warrants it
- Auditable throughout the elevation
- Limited to the role required for the task
One-to-one mapping between privileged roles and role groups, supported by Microsoft Entra Privileged Identity Management settings and access reviews. This creates a clearer relationship between a user’s eligibility and the administrative capability they can activate.
Avoid combining several unrelated roles into a single elevation path purely for convenience. If a user activates User Administrator, Intune Administrator and Group Administrator together, the effective privilege may exceed the requirements of the task.
Role elevation should therefore be designed around specific administrative duties, not around giving an administrator a broad toolkit “just in case.”
Protect Elevation with Phishing-Resistant Authentication
Traditional multifactor authentication is valuable, but not all authentication methods provide equal resistance to modern phishing techniques.
Guarding high-privilege elevation through Conditional Access policies that require strong, phishing-resistant authentication.
Passkeys for administrative accounts, including onboarding through a Temporary Access Pass and representing passkeys through an authentication strength in Conditional Access.
The key is to connect multiple controls. A strong design does not apply phishing-resistant authentication only when the administrator initially registers an account. It associates the stronger requirement with privileged access and sensitive administrative activity.
Token Protection
Token protection as an additional control for high-privilege elevation. This reflects an important architectural principle: successful authentication should not be treated as the end of the security decision. The resulting session and token must also be protected.
Protected Actions
For particularly sensitive operations, protected actions can provide another policy boundary. Creating an authentication context, associating it with protected actions, and connecting that context to a Conditional Access policy requiring a passkey.
Device Compliance Matters
Strong authentication cannot compensate for an unmanaged or compromised administrative endpoint.
Environments where device-compliance signals are ignored and Conditional Access is not used to manage access to critical resources.
Privileged workstations or compliant devices for administrative operations, with Conditional Access denying access from non-compliant devices.
This establishes an important, layered decision:
- Is the user permitted to perform the action?
- Is the required role currently active?
- Was strong authentication completed?
- Is the session protected appropriately?
- Is the administrator using an approved and compliant device?
Make Identity Governance Continuous
Privileged access should not persist simply because it was once approved.
Periodic access reviews for Privileged Identity Management groups to confirm that members continue to require privileged capabilities. It also identifies the value of detecting inactive users and removing disabled users from privileged access arrangements.
Useful review questions include:
- Does the user still perform the function associated with the role?
- Is the role appropriately scoped?
- Is the assignment still needed?
- Has the identity become inactive or disabled?
- Is there evidence that the privilege has been used?
- Can the role be removed or replaced with a narrower role?
The duration of eligibility matters as well. Limiting how long users remain eligible for highly privileged roles. It also proposes treating the Privileged Role Administrator function separately, with strong authentication required when that role is elevated.
This helps avoid an environment where the people who administer privileged-role assignments automatically accumulate numerous other eligible roles.
Maintain Emergency Access Without Normalising Its Use
Emergency or break-glass accounts are necessary for scenarios where normal administrative access is unavailable. They should not, however, become convenient alternatives to properly governed privileged access.
Break-glass accounts should not be used for daily activities. It also calls for those accounts to be maintained, tested periodically and covered by reporting, with passkeys identified among the considerations.
An effective emergency-access design should preserve availability without creating an invisible permanent backdoor. That means the organisation needs operational ownership, monitoring and a repeatable validation process.
You Cannot Govern What You Cannot See
A control that is neither logged nor monitored provides limited assurance.
Microsoft Entra ID and Privileged Identity Management audit logs with Log Analytics, Logic Apps and a SIEM. It also highlights alerts, actions and playbooks as part of the monitoring model.
Visibility should cover both configuration and behaviour, including:
- Changes to privileged-role assignments
- Role activations and their duration
- Repeated or unusual elevation attempts
- Emergency-account usage
- Authentication-strength failures
- Administrative access from unexpected devices
- Changes to Conditional Access and governance controls
The objective is not simply to collect logs. The objective is to turn privileged identity activity into actionable security information.
What Good Identity Security Architecture Looks Like
A mature identity security architecture is not a single Microsoft Entra ID setting. It is an integrated control system.
A sensible target model brings together:
- Correctly scoped Microsoft Entra roles
- Conditional Access policies
- Phishing-resistant authentication strengths
- Identity governance
- Just-in-time privileged access
- Least-privilege role design
- Elevation rules, justification and approval
- Reporting and audit logs
- Protected actions
- Device compliance
- Protected administrative workstations
No individual component is sufficient by itself. Separate accounts without just-in-time access still leave standing privilege. Passkeys without device controls still permit administration from risky endpoints. Access reviews without useful logs may confirm assignments without revealing how those privileges are used.
The controls become effective when they reinforce one another.
Conclusion
The most important identity-security lesson is not that attackers are exceptionally creative. It is that organisations sometimes make an attacker’s job easier through designs optimised for administrative convenience rather than containment.
Assess the current identity environment. Identify standing privileges, broad role assignments, synchronised administrative identities, weak authentication paths, unmanaged administrator devices and unreviewed access. Using mechanisms such as Identity Secure Score and Zero Trust assessment tools to support this evaluation. Then redesign the path.
Separate administrative identities. Remove unnecessary standing access. Require just-in-time elevation. Protect sensitive activity with phishing-resistant authentication, compliant devices and appropriate Conditional Access controls. Review privilege regularly and make every important action visible.
Attackers will continue to look for the easiest route through an organisation. Strong identity security architecture ensures that the route they find is narrow, temporary, monitored and difficult to traverse.
