PIM Exclusion List — Accounts Outside Privileged Identity Management

Story: PIMA-003 Scope: Cirius Group Azure AD PROD tenant (ciriusgroup.com, tenant d477c9f8) and DDE tenant (ciriusdde.com, tenant ff1c5d68). Owner: Rory (architect and sole approver) Review cadence: Quarterly alongside the annual-review-checklist.md cycle.

---

Policy

All human administrative accounts in both Entra tenants MUST hold their privileged role assignments as eligible assignments activated through Privileged Identity Management (PIM). No human account should hold an active (permanent) assignment to any of the privileged roles listed below.

The only exceptions to this policy are the accounts listed in this document. Every exclusion is justified, time-bounded where possible, and reviewed quarterly.

Privileged roles this policy applies to (PROD and DDE, both tenants):

• Global Administrator
• Privileged Role Administrator
• User Administrator
• Application Administrator
• Cloud Application Administrator
• Security Administrator
• Conditional Access Administrator
• Authentication Administrator
• Privileged Authentication Administrator
• Directory Writers / Directory Readers when combined with any Admin role above
• Billing Administrator (PROD only — CTO holds via PIM)
• Exchange Administrator / SharePoint Administrator / Teams Administrator

The same principle applies to Azure RBAC at subscription scope: Owner, User Access Administrator, Contributor, and the Key Vault Admin roles must be PIM-eligible for humans, never active.

---

Exclusion Categories

1. Break-glass accounts — ALWAYS EXCLUDED

Break-glass accounts are the emergency path when PIM itself, Conditional Access, or the primary admin account is unavailable. They must be permanently active. PIM activation is blocked on these accounts by design — putting them behind PIM would defeat their purpose (the first failure scenario we plan for is "PIM / MFA / CA is the failure").

Account	Tenant	Permanent role
cirius-breakglass@ciriusgroup.com	PROD (ciriusgroup.com)	Global Administrator — active, permanent
cirius-breakglass@ciriusdde.com	DDE (ciriusdde.com)	Global Administrator — active, permanent

Compensating controls (required for all break-glass accounts):

• FIDO2 hardware key stored in the on-site physical safe. No password. No phone auth.
• Conditional Access policy specifically excluding these accounts from MFA requirement on the break-glass key registration path. All other CA policies apply.
• break_glass_agent.py and break_glass_agent_prod.py raise a CRITICAL incident in SecOps on any activity (sign-in, token issue, role change). No suppression. No known-good rules. Enforced at the SecOps API — the platform rejects known-good rules whose subject matches the break-glass UPN.
• Quarterly test — a scheduled exercise exercises the key, proves the safe access, confirms the account still works. Results logged in the Annual Review.

These accounts are permanently excluded. Do not move them to PIM.

Additional break-glass identities outside Entra (documented here for completeness, PIM does not apply — different platforms):

• On-prem AD break-glass: 3 accounts, sealed envelopes in the safe
• AWS root: 7 accounts, one per Organizations-member account, MFA keys in the safe
• Palo Alto local admin: 1 per firewall (4 total), credentials in the safe

---

2. Service accounts and automation SPs — EXCLUDED

Non-human identities cannot use PIM — PIM requires interactive activation, which requires an interactive user. These identities rely on role assignments that are active-permanent by necessity, and are compensated for with other controls (managed-identity RBAC scoping, API key expiration, sign-in monitoring via sp_signin_agent.py / sp_signin_dde_agent.py).

Account	Tenant	Purpose	Compensating control
Entra Connect sync account (on-prem AD to Entra PROD)	PROD	Directory sync	Synced from AD, password auto-rotated by Azure AD Connect. Sign-in monitoring via entra_audit_agent
Entra Connect sync account (on-prem AD to Entra DDE)	DDE	Directory sync	As above
cirius-kobe-bot (GitHub bot account)	GitHub only — not Entra	CI PRs and review	Member (not owner) of the org, branch protection enforced, least-privilege PAT scopes
id-agents-prod (User-assigned managed identity, logging sub)	PROD	Security agents runtime	RBAC scoped to specific resources (see compliance/lpriv-secops-audit.md LPRIV-002/005)
id-secops-prod (User-assigned managed identity, logging sub)	PROD	SecOps web app runtime	KV Secrets User + AcrPull only
github-deploy-app (OIDC federated credential)	PROD / DDE	Terraform apply from GitHub Actions	OIDC federated — no stored secret, subject-scoped to repo:Cirius-Group-Inc/*
cirius-findings-tracker (app registration)	PROD	SecOps web app Graph access	3 application permissions, all audited in LPRIV-001
Cirius SecOps Bot (app registration)	PROD	Teams bot	1 application permission, audited in LPRIV-001b
twingate-law-ingest (app registration)	PROD	Twingate to LAW ingest	Single-purpose, secret in KV with expiration_date
panorama-backup SP	PROD	Palo Alto config backup to S3	Scoped to backup path only
cirius-findings-tracker function app identity	PROD	Findings tracker webhook	No Entra roles — only resource-level RBAC

All service accounts and SPs are documented in Terraform (azure-infra/entra/*.tf for Entra, azure-infra/modules/* for managed identities). Any new service account MUST be added to this table in the same PR that creates it.

---

3. Vendor emergency-access accounts — EXCLUDED, heavily restricted

Rare category for vendor-side accounts that must retain active access for incident response (e.g. Microsoft Premier Support, Arctic Wolf MDR).

Account / Principal	Tenant	Purpose	Compensating control
Arctic Wolf MDR federated service principal	PROD + DDE	MDR act-first authority	SP, scope-limited RBAC, signed contract, CA policy restricting source IPs to Arctic Wolf NAT ranges

Arctic Wolf is the only current vendor holding an exclusion. No other vendor should be added without explicit Rory approval AND a documented business justification in this file.

---

All other admin accounts — PIM-managed, NO exceptions

All remaining human admin accounts in both tenants MUST be PIM-eligible, including:

• Rory's admin (rory.admin@ciriusgroup.com, rory.admin@ciriusdde.com)
• Kevin's T1 DR admin
• Greg's T1 DR admin
• Any future admin onboarded

Activation window: default 4 hours, max 8 hours. Approver: Rory (self-approval for Rory's own account; Kevin/Greg self-approve with justification and a 2-hour slack notification). All PIM activations log to Entra audit logs and flow to cirius-logging-law-central for the identity_agent / entra_audit_agent review cycles.

---

Quarterly Review Actions

Each quarter:

1. Run az rest --method get --url 'https://graph.microsoft.com/v1.0/directoryRoles' in both tenants and diff active-member lists against this exclusion list. Any human admin with an active assignment not covered above is a finding.
2. Verify break-glass accounts still authenticate successfully against their FIDO2 keys (quarterly test).
3. Verify all service accounts listed here still exist in Terraform. Orphaned entries (service account removed but doc not updated) are findings.
4. Confirm the Arctic Wolf exclusion is still contractually justified.

PIMA-008 tracks an adjacent review of PIM approval workflow activity (pending and denied requests); that KQL review runs on the same quarterly cadence.

---

Related Documents

• compliance/lpriv-secops-audit.md — LPRIV audit of service account RBAC scopes
• security/lpriv-baseline.md — least-privilege baseline policy
• runbooks/incident-response.md — break-glass escalation procedure
• compliance/annual-review-checklist.md — parent quarterly review cycle

Document History

Date	Change	Author
2026-04-16	Initial version — PIMA-003 exclusion list with all categories enumerated	Kobe