Runbook: Admin Account Hygiene

Purpose: Quarterly review of every account with elevated privilege across both Entra ID tenants, both on-prem AD forests (until domain consolidation completes), Palo Alto admin accounts, AWS IAM, and service principals. Catches stale, unused, or unexpected privilege before it becomes an incident. Supports HIPAA §164.308(a)(3), §164.308(a)(4), and SOC2 CC6.1.

Owner: Rory (Security Officer) Audience: Rory, DR admins (Kevin, Greg) Cadence: Quarterly — first week of January, April, July, October Estimated time: 90 minutes Tracking: Open a SecOps story per quarter with category=admin-hygiene; each unchecked box becomes a sub-task

---

Tenant-scoped reviews

A. Entra ID PROD tenant (ciriusgroup.com, tenant d477c9f8)

• [ ] Global Administrator role members — list all via Entra portal → Roles & administrators → Global Administrator → Assignments. Expected count matches security/lpriv-baseline.md. Any unexpected member investigated before close.
• [ ] Privileged Role Administrator role members — list via the equivalent path. Expected count matches baseline.
• [ ] Each privileged account's last sign-in — filter for activity in past 90 days. Any account inactive >90 days: initiate PIM removal or documented exception.
• [ ] Privileged accounts' MFA / FIDO2 enrollment — confirm each has MFA; target FIDO2 for all (ongoing, see compliance/risk-acceptance-register.md RA-2026-001).
• [ ] PIM eligible-only assignments — confirm no standing (permanent-active) Global Admin or Privileged Role Admin assignments. Only break-glass accounts should show as permanent-active.
• [ ] Service principals with Owner role — list all SPs with Owner on any subscription. Expected: only the Terraform deploy SPs. Any other Owner SP investigated.
• [ ] Service principals with Global Admin API permissions — review consented app permissions against security/lpriv-baseline.md.

B. Entra ID DDE tenant (ciriusdde.com, tenant ff1c5d68)

• [ ] Global Administrator role members — Expected: DDE-specific admin accounts + break-glass only.
• [ ] Privileged Role Administrator role members — per baseline.
• [ ] Privileged accounts' last sign-in (90d) — same as PROD.
• [ ] MFA / FIDO2 enrollment — confirm.
• [ ] PIM posture — no standing privileged assignments (break-glass excepted).
• [ ] Service principals with Owner — only the DDE Terraform deploy SP expected.
• [ ] B2B guest accounts — review guests; remove any no longer needed.

C. On-prem AD forests

Until domain consolidation completes (see azure/domain-consolidation-plan.md), review each forest separately.

• [ ] Domain Admins membership (Forest A — legacy) — expected empty except migration service account during Phase 3
• [ ] Domain Admins membership (Forest B — Azure PROD) — expected: break-glass accounts only + explicitly-approved admin
• [ ] Enterprise Admins — expected: empty or break-glass only
• [ ] Schema Admins — expected: empty
• [ ] Account Operators / Backup Operators / Print Operators — expected: empty or bound to specific non-human service identities
• [ ] Protected Users group — all T0/T1 human admins are members
• [ ] Stale computer accounts — run Get-ADComputer -Filter * -Properties LastLogonDate (via elevated admin session logged in Keeper). Any computer inactive >90 days: disable and tag for removal unless documented exception.
• [ ] Stale user accounts — same treatment for user accounts.
• [ ] iMacros PC exception — confirm the three iMacros PCs in Forest A are documented per azure/domain-consolidation-plan.md §4 and have current Cortex + Arctic Wolf coverage.

D. Palo Alto (4 VM-Series + Panorama)

• [ ] Named admin accounts per firewall — expected: Rory + one backup (Kevin or Greg) + break-glass local
• [ ] Last login per admin — must be within 90 days or documented exception
• [ ] Panorama admin accounts — same review
• [ ] Role assignments — superuser reserved for break-glass only; default is role-scoped
• [ ] Break-glass local account — any sign-in in past 90 days = CRITICAL investigation

E. AWS (7 accounts)

• [ ] Each account's root account — MFA on, access key NEVER present, password rotated annually
• [ ] github-deploy-main role assumptions — last used within 30 days (CI/CD is actively deploying)
• [ ] IAM users — none expected; all access via SSO
• [ ] IAM roles with AdministratorAccess — limited to github-deploy-main + explicit emergency roles
• [ ] Service-linked roles — expected set per security/lpriv-baseline.md
• [ ] Stale access keys — any key older than 90 days in any account: rotate immediately

F. SecOps platform

• [ ] Writer role members — match the SecOps Entra group ffdf1dcb; remove any account not in that group
• [ ] API keys in Key Vault — each key has a known user/service owner; any unknown key rotated and investigated
• [ ] known-good rules with broad scope — review any rule affecting >1% of findings; verify Rory approved each

---

Break-glass accounts — every quarter without exception

Any sign-in activity on a break-glass account produces a CRITICAL incident that cannot be suppressed (API-level block per CLAUDE.md hard rule). This quarterly review double-checks that suppression invariant.

For each of the 18 break-glass accounts (3 on-prem AD, 7 AWS root, 2 Entra PROD, 2 Entra DDE, 4 Palo Alto local):

• [ ] Last sign-in timestamp — should be 0 (no activity) or match a documented DR drill. Any other activity = CRITICAL immediate investigation.
• [ ] Credential storage integrity — verify Keeper record exists and access-log shows expected maintainers only
• [ ] Physical safekeeping — for accounts with offline-stored credentials, confirm sealed-envelope integrity
• [ ] Suppression check — verify account is listed in the unsuppressible set; query SecOps API to confirm POST /api/known-good rejects attempts to include break-glass identity
• [ ] Viability drill (twice-yearly, not each quarter) — test sign-in against a break-glass account in a controlled way to confirm it still works

---

Output and follow-up

After running the checklist:

1. Any unchecked item without documented resolution becomes a SecOps sub-story with owner and due date
2. Any HIGH or CRITICAL finding is escalated immediately; do not wait for quarter-end
3. Deltas from the prior quarter are summarized in a short memo attached to the parent SecOps story
4. Update security/lpriv-baseline.md if any intentional change to the baseline occurred this quarter (do NOT silently accept drift)
5. File the completed checklist at SharePoint → Compliance → Quarterly Reviews → <YYYY-Q#> → admin-account-hygiene-<YYYY-Q#>.md

Common remediations

Finding	Action
Unknown Global Admin	Disable account, investigate path of grant, rotate credentials of any reachable user, root-cause analysis within 48h
Service principal Owner not in baseline	Remove Owner; add narrowly-scoped RBAC role; update baseline if intentional
Break-glass account recent sign-in	Declare P1 per runbooks/incident-response.md; rotate credential; investigate
Stale privileged account (>90d inactive)	Remove from PIM eligibility; archive account; notify owning manager
Access key >90d old	Rotate immediately; investigate why rotation SLA missed
Panorama admin last login >90d	Remove account or tag for removal next quarter

Cross-references

• security/lpriv-baseline.md — the source of truth for expected admin populations
• compliance/annual-review-checklist.md — quarterly LPRIV audit schedule
• compliance/hipaa-administrative-procedures.md §3 and §4 — workforce security and access management procedures
• compliance/compliance-scorecard.md row 34 — least privilege baseline control
• azure/domain-consolidation-plan.md — informs Forest A scope in section C
• runbooks/monthly-security-review.md — monthly identity review; this runbook is the quarterly complement

Document history

Date	Change	Author
April 2026	Initial admin account hygiene quarterly runbook	Kobe