How to Control the Hidden Admin That Grants Everyone Access

A single hidden admin can undo years of careful least-privilege work in under five minutes. In multiple 2026 incident reviews, the root cause was not a breached global admin account, but a quieter identity with the power to assign roles, modify group membership, or approve elevated access for others. If one account can decide who gets access, that account is your real control plane.

Most teams document administrators. Fewer teams document permission setters: the account, service principal, break-glass role, IdP group owner, or workflow approver that determines who becomes admin next. That gap is where privilege escalation survives audits.

Why the hidden admin matters more than your visible admins

Your org chart says one thing. Your authorization graph says another.

A visible admin is easy to spot: Global Administrator, Organization Owner, root, superuser. The hidden admin is the identity that can grant one of those roles, directly or indirectly. In practice, that might be:

• An Entra ID Privileged Role Administrator who can assign Global Admin
• An Okta group owner who controls a group mapped to AWS AdministratorAccess
• A GitHub Enterprise owner who can add members to a platform team synced into Kubernetes RBAC
• A Terraform Cloud service account that can update IAM bindings across projects
• A CI/CD runner role with iam:PassRole and sts:AssumeRole paths into production

The real risk is delegated privilege, not static privilege

Static admin lists miss transitive control. Example: a platform engineer has no production admin role. But they own an identity group called prod-breakglass-approvers. That group can approve just-in-time elevation in your PAM tool. They are not an admin on paper, yet they determine who becomes one.

That distinction matters because attackers map delegation paths quickly. In red-team exercises run against large SaaS estates in 2026, teams often found 3-7 indirect paths from a standard engineering account to high privilege through group ownership, role assignment APIs, or automation tokens.

One realistic failure chain

Consider a mid-market SaaS company running Microsoft Entra ID, AWS Organizations, GitHub Enterprise Cloud, and Kubernetes on EKS:

1. A helpdesk automation app has permission to update Entra groups.
2. One Entra group is mapped via SCIM to an Okta app assignment.
3. That app assignment grants access to an internal platform portal.
4. The platform portal can request AWS admin elevation through an approval workflow.
5. Approvers are drawn from a GitHub team managed by a repo-level CODEOWNERS file.

No single step looks catastrophic in isolation. Together, they create a hidden admin chain. Compromise the automation app or the repo owner, and you can influence who gets production access.

How to identify the account that really sets permissions

You need a graph, not a spreadsheet.

Start by asking one narrow question for each critical platform: Who can grant or approve admin access here? Then expand outward to include all identities that can change that answer.

Build a permission-setting inventory

Track these objects first:

• Role assignment administrators n- Group owners for security groups synced into apps or clouds
• PAM/PIM approvers and policy editors
• Service accounts with IAM write access
• CI/CD identities with assume role, pass role, or policy update rights
• Break-glass accounts and who can reset or enroll MFA for them
• Repository owners for infrastructure-as-code and policy repos

A simple inventory table works as a starting point:

Query for transitive control paths

Use your cloud and identity APIs to find who can alter assignments, not just who currently holds them.

# Example: AWS IAM role paths that can lead to admin through pass-role or assume-role
aws iam list-roles --query 'Roles[].RoleName' --output text | tr '\t' '\n' | while read role; do
  aws iam list-attached-role-policies --role-name "$role" \
    --query 'AttachedPolicies[].PolicyArn' --output text | grep -E 'AdministratorAccess|IAMFullAccess' && echo "$role"
done

# Example: Microsoft Graph query for role assignment capable identities
Connect-MgGraph -Scopes "RoleManagement.Read.Directory,Directory.Read.All"
Get-MgRoleManagementDirectoryRoleAssignmentScheduleInstance | Select-Object PrincipalId,RoleDefinitionId,DirectoryScopeId

// Example: Neo4j/BloodHound-style graph query for transitive privilege setters
MATCH p=(u:Identity)-[:OWNS_GROUP|CAN_ASSIGN_ROLE|CAN_APPROVE|CAN_PUSH_POLICY*1..4]->(r:Role {name:'Global Administrator'})
RETURN p
LIMIT 50

In mature environments, this exercise usually reveals that 2-4 times more identities can set admin permissions than the number of identities currently holding admin permissions.

Measure blast radius with one metric

Track permission setter ratio:

permission setter ratio = identities that can grant admin / identities that currently hold admin

If you have 18 production admins but 61 identities that can grant or approve production admin, your ratio is 3.39. That is a useful board-level signal because it captures hidden control, not just visible access.

For most enterprises, a healthy target in 2026 is under 1.5 for tier-0 systems and under 2.0 for tier-1 systems. Higher than that usually means group sprawl, weak approval chains, or automation with broad write privileges.

Design a safer delegation model without slowing delivery

You do not need zero delegation. You need constrained delegation.

The best-performing teams separate operational admin from permission-setting admin. The first fixes incidents. The second changes who can fix incidents. Those should rarely be the same identity class.

Use a two-layer model

Layer 1 is execution access:

• Engineers get JIT elevation for time-bound admin tasks
• Sessions are logged
• Access expires automatically after 30-120 minutes

Layer 2 is permission-setting access:

• Only a small set of identities can alter role assignments, group ownership, or approval policies
• Changes require stronger controls: phishing-resistant MFA, device trust, dual approval, and immutable logging
• No CI/CD token should hold both deployment and IAM-write power for the same environment

Example policy design for AWS

A common mistake is letting your deployment role update both infrastructure and IAM. Split those powers.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DeployAppOnly",
      "Effect": "Allow",
      "Action": [
        "ecs:UpdateService",
        "lambda:UpdateFunctionCode",
        "cloudformation:DescribeStacks"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyPrivilegePath",
      "Effect": "Deny",
      "Action": [
        "iam:PassRole",
        "iam:AttachRolePolicy",
        "iam:PutRolePolicy",
        "sts:AssumeRole"
      ],
      "Resource": "*"
    }
  ]
}

This pattern removes the hidden admin path from your build pipeline. In one enterprise migration, splitting deployment and IAM administration reduced high-risk privilege escalation findings by 42% in the first quarter.

Put approvals outside the team being approved

If the same platform team can request, approve, and audit its own elevation, you have built a loop, not a control.

Use cross-functional approvers for tier-0 systems:

• Platform requests approved by security engineering or SRE leadership
• Identity policy changes approved by identity engineering plus security
• Break-glass use reviewed after the fact by an independent control owner within 24 hours

That extra step adds minutes, not days. Modern PAM tools in 2026 typically complete policy-backed JIT approval in 45-90 seconds for standard workflows.

Instrument the control plane: logs, alerts, and drift detection

If you cannot see permission-setting events, you cannot defend them.

Focus your telemetry on changes to who can grant access, not only on access usage itself.

Events you should alert on

At minimum, create high-severity alerts for:

• New owner added to an identity or SCIM-synced group
• New admin role assignment or eligibility assignment
• Changes to PIM/PAM approval policy
• New API token or service principal with directory write or IAM write permissions
• Changes to break-glass account credentials, MFA methods, or recovery settings
• Commits to IAM, RBAC, or policy repositories outside approved pipelines

Example detection rules

title: Hidden admin path created via group ownership
logsource:
  product: identity
  service: audit
condition: selection
selection:
  event_name:
    - Add group owner
    - Update group owners
  target_group_tags|contains:
    - privileged
level: high
fields:
  - actor
  - target_group
  - new_owner

title: CI role gained IAM write capability
logsource:
  product: aws
  service: cloudtrail
condition: selection
selection:
  eventSource: iam.amazonaws.com
  eventName:
    - AttachRolePolicy
    - PutRolePolicy
  userIdentity.sessionContext.sessionIssuer.userName|contains: ci
level: critical

Detect drift between intent and reality

Your source of truth should be code plus approval records. Compare that against live state daily.

# Simplified drift check: compare approved privileged group owners to live owners
approved = {"prod-admin-approvers": {"alice","bob"}}
live = fetch_group_owners_from_idp()
for group, owners in live.items():
    if group in approved and set(owners) != approved[group]:
        print(f"DRIFT: {group} owners live={owners} approved={sorted(approved[group])}")

Teams that run daily drift checks on privileged groups usually cut mean time to detect unauthorized permission changes from days to under 30 minutes, assuming logs are centralized and alerts are routed correctly.

Common Pitfalls

Treating break-glass as exempt from governance

Break-glass accounts often become the hidden admin of last resort. Teams store credentials in a vault and stop there.

Avoid this by enforcing:

• Hardware-backed phishing-resistant MFA where supported
• Quarterly live-fire access tests
• Separate recovery admins who cannot grant themselves standing privilege
• Immediate review for any sign-in, credential reset, or MFA change

Letting group ownership sprawl

A group looks harmless until it is mapped into five systems. One Platform-Admins-Eligible group in Entra can flow into GitHub, Atlassian, AWS Identity Center, and internal tooling.

Avoid this by limiting privileged group owners to a tiny named set, banning nested ownership, and tagging groups with a privileged=true attribute that drives stronger policy.

Giving automation broad write access because it is convenient

Service accounts are patient attackers. They do not take vacations, and they rarely trigger human review.

Avoid this by splitting duties across automation identities, using short-lived workload identity federation instead of long-lived secrets, and denying IAM mutation from standard deployment paths.

Auditing current admins but not future admins

A quarterly admin review that asks "Who has admin now?" misses the more dangerous question: "Who can make someone admin tomorrow?"

Add permission setters to every access certification. If your GRC tooling cannot model this, export the graph and review it separately.

Relying on one control layer

MFA alone will not save you if the wrong account can reset MFA for others. Approval workflows alone will not save you if approvers are controlled by the requesting team.

Layer controls: hardened identities, constrained delegation, independent approval, immutable logs, and drift detection.

Key Takeaways

• Identify your permission setters, not just your current admins; they are often the real hidden admin.
• Measure permission setter ratio for tier-0 and tier-1 systems, and drive it down with ownership cleanup.
• Split operational admin from permission-setting admin so deployment and incident response do not also control IAM.
• Alert on group ownership, role assignment, PAM policy changes, and break-glass recovery events with high severity.
• Run daily drift checks between approved privileged ownership and live state; this is one of the fastest wins you can ship this week.
• Review every path where code, automation, or group sync can indirectly grant admin, especially across Entra, Okta, AWS, GitHub, and Kubernetes.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.