Break-Glass Account Activation Procedure

Purpose

Break-glass accounts are emergency credentials that bypass normal MFA, Conditional Access, and SSO requirements. They exist for situations where normal authentication is broken or unavailable — a Conditional Access misconfiguration that locks everyone out, identity provider outage, or a security incident requiring out-of-band access.

These accounts are permanently monitored and unsuppressible. Any login triggers a CRITICAL incident in SecOps with no suppression path. If you use one, expect alerts. That is by design.

Never use a break-glass account for routine work. If you have a valid reason to use one, document it before or immediately after.

---

Break-Glass Account Inventory

Azure Entra PROD (ciriusgroup.com, tenant d477c9f8)

Account	Use Case
cirius-breakglass@ciriusgroup.com	Complete Entra lockout — all normal admin accounts inaccessible

Credentials: Keeper vault → "Break Glass — Azure PROD"

Azure Entra DDE (ciriusdde.com, tenant ff1c5d68)

Account	Use Case
cirius-breakglass@ciriusdde.com	Complete Entra lockout in DDE tenant

Credentials: Keeper vault → "Break Glass — Azure DDE"

On-Premises Active Directory (ciriusgroup.com internal forest)

3 break-glass accounts with Domain Admin rights. Not synced to Entra — AD-local only.

Credentials: Keeper vault → "Break Glass — On-Prem AD"

AWS Root Accounts (7 accounts)

One root account per AWS account. Root credentials bypass all IAM policy.

Account	ID
Management	206820231356
Backup	863609217450
Dev	040067931468
Identity	414134953818
Logging	038901680748
Networking	238342914131
Prod	807267566999

Credentials: Keeper vault → "AWS Root — [Account Name]"

Root accounts require the physical MFA token kept in the office. If remote access to the root account is needed without the token, use the account recovery flow — see AWS documentation.

Palo Alto Local Admin (4 firewalls)

Each firewall has a local admin account independent of Panorama/LDAP. Use when Panorama is unreachable or LDAP authentication is broken.

Firewall	Management IP	Notes
PublicFW-PROD	(see Keeper)	Public-facing firewall, Azure PROD
PrivateFW-PROD	(see Keeper)	Internal firewall, Azure PROD
PublicFW-AWS	(see Keeper)	Public-facing firewall, AWS networking account
PrivateFW-AWS	(see Keeper)	Internal firewall, AWS networking account

Credentials: Keeper vault → "Palo Alto Local Admin — [firewall name]"

Total: 18 break-glass accounts across all systems.

---

When to Use Break-Glass

Use break-glass only when normal access is completely unavailable AND the situation cannot wait for the next business day.

Scenario	Account to Use
Conditional Access policy locked out all Entra accounts	cirius-breakglass@ciriusgroup.com or DDE
MFA provider outage with no bypass available	cirius-breakglass@ciriusgroup.com
Entra Identity Protection blocked all admins	cirius-breakglass@ciriusgroup.com
Active security incident — normal admin credentials compromised	cirius-breakglass@ciriusgroup.com
AWS IAM misconfiguration locked out all IAM users/roles	AWS root for affected account
Palo Alto Panorama unreachable, need firewall config change	Palo Alto local admin
On-prem domain controller emergency requiring DA access	On-prem AD break-glass

Do not use break-glass to save time or avoid an approval process. That is a HIPAA/SOC2 control failure and will be flagged in the next audit.

---

Activation Procedure

Step 1 — Document First

Before or immediately after break-glass use, record in SecOps or your incident log:

• Date and time
• Which account you used
• Why normal access was unavailable
• What you did with the access
• When you exited the break-glass session

If SecOps itself is unavailable (infrastructure incident), log in a dated text file and add it to SecOps when restored.

Step 2 — Retrieve Credentials

Open Keeper. The break-glass vault entries are in the "Break Glass" folder.

If Keeper is unreachable and this is an active incident:

• The out-of-band communications plan covers credential retrieval from the offline kit
• See Out-of-Band Communications Plan

Step 3 — Access the System

For Entra break-glass accounts:

1. Open a private/incognito browser window
2. Navigate to https://portal.azure.com
3. Sign in with the break-glass account — it is excluded from all Conditional Access policies
4. Diagnose and remediate the root cause
5. Verify normal admin access is restored before ending session

For AWS root accounts:

1. Go to https://console.aws.amazon.com
2. Select "Root user" at the login screen
3. Enter the root email address for the account (see Keeper)
4. Complete MFA using the physical token
5. Perform only the minimum action needed to restore IAM access
6. Sign out immediately

For Palo Alto local admin:

1. SSH or browse directly to the firewall management IP (not via Panorama)
2. Use the local admin credentials from Keeper
3. Make only the minimum required change
4. Document the change in the change log

For on-prem AD break-glass:

1. Console access to a domain controller is required (not remote unless DC is accessible)
2. Log in with the break-glass DA account
3. Make only the minimum required change
4. Log off immediately

Step 4 — Alert the Team

Break-glass use will auto-generate a CRITICAL incident in SecOps (if SecOps is running). Do not suppress it. Acknowledge it in the platform with your documentation from Step 1.

If in an active incident with Kevin or Greg, notify them that break-glass was used and what action was taken.

Step 5 — Post-Access Review

Within 24 hours of break-glass use:

1. Confirm the root cause of the lockout is resolved
2. Verify the break-glass account has been signed out of all sessions
3. Rotate the break-glass account password if there is any possibility it was exposed
4. Add an entry to the Risk Acceptance Register documenting the use and outcome
5. Update the HIPAA incident log if PHI systems were accessed

---

What Break-Glass Does NOT Allow

Even with break-glass access, these actions are prohibited without explicit approval:

• Suppressing the break-glass alert in SecOps — impossible, hard-blocked at API layer
• Adding break-glass accounts to known-good rules — hard-blocked at API layer
• Bulk-deleting resources or disabling security controls without a documented incident
• Using the break-glass session beyond what is required to restore normal access

---

Quarterly Verification

Break-glass account health is verified quarterly. Verification confirms:

• Credentials are current and retrievable from Keeper
• Accounts have not been used since last verification (or documented use is on file)
• Accounts are excluded from Conditional Access and PIM enforcement
• MFA tokens (AWS) are operational

See Annual BGKIT Verification for the annual hardware/offline kit check.

---

Related Documents

• Out-of-Band Communications Plan — how to communicate when primary channels are down
• Incident Response — general incident procedures
• Security Monitoring Architecture — how the CRITICAL alert is generated
• Risk Acceptance Register — post-use documentation

---

Document History

Date	Change	Author
May 2026	Initial draft — consolidates break-glass account inventory and activation procedure from CLAUDE.md and security architecture	Rory