Protect root and global admin accounts with hardware MFA and alerts

TL;DR — Protect your cloud root account and your tenant-wide global administrator account with at least two hardware security keys each, then remove day-to-day use, store one emergency credential set offline, and alert on every sign-in or MFA change. The most common gap is leaving these accounts on app-based MFA or reusing them for normal admin work; fix that first. Reading time: ~5 min

Goal

When you finish, your root and global administrator accounts will require hardware MFA, have a documented break-glass recovery path stored offline, and generate alerts on every sign-in and credential change so emergency use is visible immediately.

Prerequisites

• Access to your cloud provider root account and your identity provider or tenant global administrator account
• Permission to change MFA methods, conditional access or authentication policy, and audit/log alerting
• Two hardware security keys per privileged account, preferably FIDO2/WebAuthn-capable keys from different batches/vendors
• One offline storage location for the break-glass package: sealed envelope in a safe or an encrypted password manager vault with restricted access
• A shared alert destination: security mailbox, Slack/Teams webhook receiver, PagerDuty email integration, or SIEM collector
• A workstation with:
  • bash or equivalent shell
  • openssl >= 3.0 — check with openssl version
  • jq >= 1.6 — check with jq --version
  • curl >= 8.0 — check with curl --version
• The exact usernames/email addresses of the root account and the global administrator accounts you are protecting
• A runbook location you can edit, for example docs/security/break-glass.md

Steps

Step 1: Inventory the privileged accounts and stop using them for daily work

Create a short inventory file with the exact account identifiers and intended purpose.

mkdir -p docs/security && cat > docs/security/privileged-accounts.txt <<'EOF'
root-account: root@example-billing-email.invalid
cloud-break-glass-admin: breakglass-cloud-admin@example.com
global-admin-primary: global-admin@example.com
global-admin-break-glass: breakglass-identity@example.com
policy: no daily use; emergency only
EOF

cat docs/security/privileged-accounts.txt

You should see the four lines printed back with the exact account names you will protect.

Step 2: Register two hardware security keys on each privileged account

In your provider dashboard, sign in as each privileged account and add two hardware keys.

Exact menu path varies by provider, but use the account security area, for example: Account/Profile → Security → Multi-factor authentication → Add security key and repeat twice, naming the keys literally primary-hwkey and backup-hwkey.

If your identity platform supports restricting methods, set the privileged accounts to allow only FIDO2 security key or WebAuthn security key and disable SMS, voice, and TOTP app for those accounts.

You should see two enrolled hardware keys on each account, both with recent registration timestamps.

Step 3: Test both keys before you lock anything down

Open a private/incognito browser window and sign in with the privileged account twice: once with primary-hwkey, once with backup-hwkey.

Use this checklist in your runbook:

cat > docs/security/mfa-test-checklist.txt <<'EOF'
[ ] root account login works with primary-hwkey
[ ] root account login works with backup-hwkey
[ ] global admin login works with primary-hwkey
[ ] global admin login works with backup-hwkey
[ ] no SMS/TOTP fallback offered
EOF

cat docs/security/mfa-test-checklist.txt

You should be able to complete sign-in with each key, and the login prompt should not offer weaker fallback methods for those accounts.

⚠️ If you disable fallback methods before testing both hardware keys, you can lock yourself out of the tenant or billing account. Finish the two-key login test first.

Step 4: Create the break-glass package and store it offline

Generate a sealed record containing the account identifier, where the keys are stored, and the recovery steps. Do not put live passwords or recovery codes in a shared wiki page.

cat > docs/security/break-glass.md <<'EOF'
## Break-glass accounts

### root-account
- username: root@example-billing-email.invalid
- MFA devices: primary-hwkey, backup-hwkey
- storage:
  - primary-hwkey: safe A, envelope 1
  - backup-hwkey: safe B, envelope 2
- use policy: emergency only
- after use: rotate password, review audit log, confirm MFA devices unchanged

### global-admin-break-glass
- username: breakglass-identity@example.com
- MFA devices: primary-hwkey, backup-hwkey
- storage:
  - primary-hwkey: safe A, envelope 3
  - backup-hwkey: safe B, envelope 4
- use policy: emergency only
- after use: rotate password, review audit log, confirm role assignments unchanged
EOF

openssl dgst -sha256 docs/security/break-glass.md

You should see a SHA-256 digest line like this:

SHA2-256(docs/security/break-glass.md)= 7c3d4d5b7f2b0d6b5f2d6c0d7d9b0d4f0d4e5a1b2c3d4e5f60718293a4b5c6d7

Print the file or export it to your approved offline vault, then store the hardware keys in two separate physical locations.

Step 5: Remove standing admin use from the break-glass accounts

For the break-glass identity account, remove it from normal operational groups and exclude it from daily sign-in workflows except where required for emergency access.

Use your provider dashboard role assignment path, for example: Identity/Directory → Roles and administrators → Global Administrator → Assignments and leave only the dedicated break-glass account plus your normal privileged access workflow accounts. Then in Applications/SSO/Conditional Access, exclude only the break-glass account from policies that could block emergency sign-in, but do not assign it to routine admin groups.

You should see the break-glass account present only in the minimum emergency role assignment and absent from day-to-day admin groups.

Step 6: Alert on every sign-in and every credential or MFA change

If your provider can send audit logs to a webhook, SIEM, or email action, create alerts for these exact event classes:

• successful sign-in by root-account
• successful sign-in by global-admin-break-glass
• failed sign-in by either account
• MFA device added, removed, or reset for either account
• password changed or recovery method changed for either account
• role assignment changed for the break-glass admin account

If you have a webhook receiver, test it with a synthetic payload:

export ALERT_WEBHOOK_URL='https://alerts.example.com/hooks/security'
curl -i -X POST "$ALERT_WEBHOOK_URL" \
  -H 'Content-Type: application/json' \
  -d '{"severity":"high","account":"breakglass-identity@example.com","event":"test-alert","source":"kb-howto"}'

Expected success shape is an HTTP 2xx response, for example:

HTTP/1.1 202 Accepted
content-type: application/json

{"status":"queued"}

If you use email-based alerting, send a test message from the provider alert rule UI to your security mailbox and verify delivery.

Step 7: Document the emergency flow and post-use cleanup

Add the exact emergency sequence to the runbook so nobody improvises during an outage.

[Incident] ---- 1. need emergency admin ----> [On-call]
[On-call] ---- 2. retrieve sealed package ----> [Safe]
[On-call] ---- 3. sign in with hw key ----> [Privileged Account]
[Privileged Account] ---- 4. perform recovery ----> [Cloud/Identity]
[Cloud/Identity] ---- 5. audit events ----> [Alerting]
[On-call] ---- 6. rotate creds and review logs ----> [Runbook]

Append this exact checklist:

cat >> docs/security/break-glass.md <<'EOF'

## Emergency use checklist
1. Open incident ticket.
2. Retrieve one hardware key from safe A or safe B.
3. Sign in only to the required provider admin surface.
4. Complete the recovery task.
5. Rotate the account password immediately after use.
6. Review sign-in, MFA, and role-change audit events for the time window.
7. Reseal or replace the used hardware key package.
EOF

tail -n 12 docs/security/break-glass.md

You should see the seven-line emergency checklist at the end of the runbook.

Verify it works

Run these checks end to end:

openssl dgst -sha256 docs/security/break-glass.md
curl -i -X POST "$ALERT_WEBHOOK_URL" -H 'Content-Type: application/json' -d '{"severity":"high","account":"root@example-billing-email.invalid","event":"verification"}'

Then verify in the provider UI:

• The root account shows exactly two enrolled hardware keys and no SMS/voice fallback.
• The global administrator break-glass account shows exactly two enrolled hardware keys and no weaker fallback methods.
• A test sign-in with backup-hwkey succeeds in a private/incognito window.
• The alert destination receives a test event and, after a real test sign-in, receives a sign-in alert within your normal logging delay.
• The break-glass document hash matches the stored copy and the physical storage locations match the runbook.

Common pitfalls

Only one hardware key is enrolled

Mistake: registering one key and planning to add the second later.

Symptom: a lost or dead key turns an outage into an account recovery event.

Fix: enroll primary-hwkey and backup-hwkey in the same session before disabling weaker MFA methods.

Break-glass account is excluded from too much policy

Mistake: excluding the emergency account from all controls, then using it for routine admin work because it is "easier."

Symptom: sign-ins from unusual locations succeed without friction and the account appears in normal audit trails every week.

Fix: keep the exclusion only for the minimum emergency sign-in path and remove the account from daily admin groups.

SMS or TOTP fallback is still enabled

Mistake: adding hardware MFA but leaving phone or authenticator-app fallback active.

Symptom: the login page still offers "text a code" or "enter verification code," which defeats the phishing-resistant goal.

Fix: in the account authentication methods policy, disable SMS, voice, and TOTP for these privileged accounts and retest in a private window.

Alerting is configured but never tested

Mistake: creating alert rules without verifying delivery to the mailbox, webhook, or SIEM.

Symptom: the rule looks enabled, but no one notices the first real break-glass sign-in.

Fix: send a synthetic webhook or provider test alert and confirm a 2xx response or inbox delivery before closing the task.

The runbook contains secrets in a shared repo or wiki

Mistake: storing live passwords, recovery codes, or key serials in a broadly readable documentation system.

Symptom: the break-glass doc itself becomes a privileged access incident.

Fix: keep the shared runbook limited to account identifiers, storage locations, and recovery steps; store live secrets only in the approved offline vault or sealed envelope.

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