Key Concepts
Access Optimization detects six distinct types of optimization opportunities. Understanding each type helps you prioritize remediation efforts and maintain least-privilege access.
Six Optimization Types
Unused Access
- Definition
- A role assignment with zero activity operations in the selected time window.
- How It's Detected
- StratoLens queries Azure Activity Logs for any operations performed by the principal within the selected time window (7-365 days). If zero activity entries are found, the assignment is flagged as unused.
- Why It Matters
- Completely unused access violates least-privilege principles and creates unnecessary security exposure. These assignments should be prime candidates for removal during security audits and access reviews.
Example Scenario
A user granted Owner role on a subscription 2 years ago who has never performed any create, update, delete, or RBAC operations in that scope during the selected time window.
Azure Platform Limitation
Activity logs only capture write operations (create, update, delete, RBAC changes), not read operations. Read-only roles like Reader are excluded from unused detection since we cannot verify usage from activity logs. This is an Azure platform limitation, not a StratoLens limitation.
Stale Access
- Definition
- A role assignment where the last activity occurred beyond the configurable "stale threshold" percentage of the selected time window.
- How It's Detected
- StratoLens finds the most recent activity timestamp for the principal within the selected time window and calculates how many days ago it occurred. If the days since last activity exceed the stale threshold percentage of the time window, it's flagged as stale.
- Why It Matters
- Access that was once used but hasn't been needed recently may indicate changed responsibilities, completed projects, or role transitions. Regular review of stale access helps maintain current and relevant permissions.
Calculation Example
With a 30-day window and 50% stale threshold:
- Stale threshold = 15 days (50% of 30 days)
- User's last activity was 20 days ago
- Result: Flagged as stale because 20 days > 15 days
Configurable Threshold
Stale threshold is configurable (default 50%, range 1-100%). Higher percentages (e.g., 70%) flag access that hasn't been used in a longer portion of the time window, focusing on clearly abandoned access. Lower percentages (e.g., 30%) flag access more aggressively.
Over-Privileged Access
- Definition
- Assignment of critical roles (Owner, User Access Administrator) without any RBAC-related operations in the activity logs.
- How It's Detected
- StratoLens checks if the role is Owner or User Access Administrator, then searches activity logs for any RBAC operations (role assignments, role definition changes, permission grants). If the principal has the critical role but zero RBAC operations, it's flagged as over-privileged.
- Why It Matters
- Critical roles grant powerful permissions including the ability to manage other users' access. If a user never exercises RBAC management capabilities, they may only need Contributor or a custom role instead, reducing security risk.
Downgrade Scenario
A user with Owner role who creates virtual machines, manages storage accounts, and configures networking but never assigns roles or manages permissions could be downgraded to Contributor without impacting their work.
Break-Glass Access Consideration
Only write operations are captured in activity logs. If a user legitimately needs Owner for disaster recovery scenarios or emergency break-glass access but hasn't used it yet, this will still flag as over-privileged. Use your judgment and document justifications for retained critical access.
Over-Scoped Access
- Definition
- A role assignment where the principal's activity is confined to less than the configured threshold percentage (default 30%) of the available scope entities.
- How It's Detected
- StratoLens counts the total number of entities in the assignment's scope (all resources in a subscription, all resource groups in a management group, etc.) using real data from the latest scan. It then counts how many unique entities the principal has performed operations on. If the percentage is below the over-scoped threshold, it's flagged.
- Why It Matters
- If a user has Contributor on an entire subscription but only ever touches resources in one resource group, their access should be scoped to just that resource group. This reduces blast radius and adheres to least-privilege principles.
Scope Efficiency Calculation
Assignment: Contributor on subscription
Total resources in subscription: 200
Resources with principal's activity: 15
Scope efficiency: 7.5% (15/200)
Threshold: 30%
Result: Flagged as over-scoped because 7.5% < 30%
Recommendation: Rescope to the specific resource group containing those 15 resources
Note
Uses real entity counts from scan data, not estimates. If a subscription only has 5 resources and the user touches all 5, scope efficiency is 100% (not over-scoped). Over-scoped threshold is configurable (default 30%, range 1-100%).
Excessive Role Sprawl
- Definition
- The same role assigned across a configured number of subscriptions (default 5+), indicating potential over-assignment.
- How It's Detected
- StratoLens groups all assignments for a principal by role name and counts how many unique subscriptions each role appears in. If the count equals or exceeds the sprawl threshold, it's flagged.
- Why It Matters
- Users with the same role across many subscriptions often indicate broad access granted for convenience rather than necessity. Consolidating to a management group assignment or removing unnecessary subscriptions maintains cleaner access management.
Investigation Workflow
Scenario:
- User has Contributor role on 12 different subscriptions
- Sprawl threshold: 5 subscriptions
- Result: Flagged as excessive sprawl
Investigation options:
If they legitimately need broad access → Grant Contributor at management group level for cleaner management
If they only actively use 3 of the 12 subscriptions → Remove Contributor from the 9 unused subscriptions
Tip
Sprawl threshold is configurable (default 5 subscriptions, range 1-50). This detection focuses on identifying patterns worth reviewing, not declaring them definitively wrong. Some users in large enterprises legitimately need broad access.
Redundant Assignment
- Definition
- A role assignment that provides duplicate permissions due to hierarchy inheritance, role supersession, or group membership overlap.
- Why It Matters
- Redundant assignments create management overhead, confusion during audits, and increase the surface area for permission errors. Cleanup simplifies access management and makes security reviews more efficient.
Three Types of Redundancy
Hierarchy Inheritance
Same role assigned at both parent and child scopes
Example:
- Contributor on subscription + Contributor on resource group within that subscription
- The subscription-level assignment already grants access to all child resource groups
Role Supersession
Multiple roles where one includes all permissions of another
Example:
- Owner + Contributor on the same resource group
- Owner includes all Contributor permissions, making Contributor redundant
Group Overlap
User has both direct assignment and assignment via group membership for the same role/scope
Example:
- User is directly assigned Reader on subscription AND is a member of a group with Reader on the same subscription
- The group membership already grants access, making direct assignment redundant
Example Scenarios
- Hierarchy: User has Contributor on subscription "Production" and also Contributor on resource group "Production-Apps" within that subscription → Remove resource group assignment (already covered by subscription)
- Supersession: User has both Owner and Contributor on resource group "Shared-Services" → Remove Contributor (Owner includes all Contributor permissions)
- Group Overlap: User Alice is directly assigned Reader on subscription "Dev" and is also a member of group "Developers" which has Reader on the same subscription → Remove direct assignment or remove Alice from group (one source of access is sufficient)
- Nested Groups: User Bob is in group "SeniorEngineers" which is nested within group "AllEngineers", both granting Contributor on the same subscription → Review group hierarchy structure rather than removing assignments
Requirements
Requires Microsoft Graph API permissions to resolve group memberships for complete redundancy detection. Management group hierarchy must be accessible for complete hierarchy inheritance detection. Nested group scenarios receive special "review" recommendations instead of "remove" because group structure may be intentional for management purposes.
Group Member Resolution
- Definition
- The process of resolving Azure AD group memberships to identify individual users, service principals, and managed identities granted access through groups, including nested group chains.
How It Works
When StratoLens encounters a role assignment to an Azure AD group, it calls the Microsoft Graph API beta endpoint /groups/{id}/transitiveMembers to retrieve all members. "Transitive" means it resolves nested groups automatically (User → Group A → Group B → Group C).
Identify all group-based role assignments during scan processing
Batch groups into sets of 20 for parallel API calls
Resolve transitive members (includes nested groups automatically)
Extract member types (User vs ServicePrincipal vs Managed Identity)
Create individual member assignments tracking source group via grantedViaGroupId field
Display nested group chains with arrow separator (→) in UI
Why It Matters
Many organizations grant access via groups for easier management, but auditors and security teams need to know which individual users actually have access. Group resolution provides user-level visibility without requiring manual Azure AD group lookups.
Critical Use Cases
- Compliance audits requiring individual user accountability
- User offboarding verification (finding all access sources including groups)
- Least-privilege reviews (identifying users who should be removed from groups)
- Security investigations (answering "who has access?" at the user level)
Group Resolution in Action
Setup: Group "AppTeam" is assigned Contributor on resource group "Production-Apps"
Group resolution reveals:
- Alice Smith (User) - member via direct group membership
- Bob Johnson (User) - member via nested group "SeniorEngineers" → "AppTeam"
- Charlie Davis (Service Principal) - member via direct group membership
UI displays:
- Alice sees
"via AppTeam"subtitle - Bob sees
"via SeniorEngineers → AppTeam"showing complete chain - Charlie sees
"via AppTeam"subtitle
Performance & Permissions
Cached for 15 minutes to reduce Microsoft Graph API calls and improve performance.
Required Microsoft Graph API permissions:
Group.Read.AllUser.Read.AllApplication.Read.All
Without these permissions, Access Optimization will show that access is granted via groups but cannot display individual group members.