Phishing-Resistant MFA for the Okta Admin Console

Rule 1 - break-glass, highest priority. Group Break-Glass-Admins, two named accounts, allow only with FIDO2, no network zone condition, session one hour. These accounts must not be federated to any external IdP, or an identity-provider outage removes your last way in.

Rule 2 - Okta-Admins. Require a phishing-resistant authenticator: FIDO2 keys, or FastPass on a managed Mac where device binding and biometric or local verification are enforced. Do not allow SMS, voice, push-only, or TOTP here; each is phishable or relayable, and allowing even one as a fallback defeats the control. Do not add a VPN/network-zone condition to this rule: the nine SREs work remotely, and forcing them to a zone pushes them into the break-glass path for routine work, which normalises break-glass usage.

Rule 3 - catch-all deny. Deny Admin Console access to everyone not in the two groups above. This is defence in depth against a misassigned admin role, not a substitute for role hygiene.

Session and global settings. Set the Admin Console session to something short, on the order of one hour idle, because console access is high value and there is no per-operation step-up. Confirm the global session policy does not quietly extend it.

Capability check before you commit. 45 admins with two keys each is 90 keys against 60 in stock plus 40 FastPass devices. Map each admin to a method first; anyone without a managed Mac needs keys ordered in the first batch. Someone enrolled in the group but holding no phishing-resistant factor is simply locked out.

Read Only Administrator is not a low-risk role from an information-security standpoint, even though it cannot change anything. A read-only administrator can enumerate the full user directory, see group structures and app assignments, read SAML and OIDC configuration including certificate details, and harvest the metadata needed to plan a targeted attack. It is a reconnaissance role, and reconnaissance is the first phase of the attack the red team just demonstrated.

Handling:

• Replace the shared vendor accounts with named accounts, one per engineer, so activity is attributable.
• Replace the built-in role with a custom role and resource set scoped to the specific application or group the vendor supports. If the vendor genuinely needs directory visibility, scope it to a group containing only their integration's users, not the whole org.
• Require the same phishing-resistant factor as internal admins, and record vendor FIDO2 keys against named individuals.
• Restrict access to the vendor's published egress IP range via a network zone, and require the access request to be approved per session rather than standing weekly.
• Review vendor access quarterly, and make the removal of an individual engineer a documented offboarding step.

The judgement point: the vendor is not an exception to the CISO's rule, and 'read only' is not a reason to weaken the authenticator requirement. It is a reason to narrow the scope.

Break-glass accounts are the most abused control in identity, because they are the one thing designed to bypass every other check. Governance has to make their use both rare and loud.

Structural controls:

• Exactly two accounts, owned by named individuals (typically the CISO delegate and the identity architect), documented in the runbook.
• Hardware keys stored sealed in a physical safe or equivalent, with a tamper-evident log and a sign-out procedure. Do not enrol them on anyone's everyday keyring.
• Credentials held outside the primary IdP so a federation outage cannot lock you out of the recovery path.
• No email, no shared mailbox, and no phone number that can be socially engineered for recovery.

Detection:

• Alert to the on-call channel on any user.session.start for either break-glass account, and again on any privileged action taken by them. The alert must page, not sit in a queue.
• Weekly review of break-glass System Log activity, including unsuccessful attempts.

Lifecycle:

• Test both accounts quarterly with a documented procedure; an untested break-glass account is a false sense of security.
• Rotate credentials and re-seal keys after every use and on any owner change.
• Record each use with a reason, an approver, and a follow-up review, and report usage to the risk committee.

The design principle: break-glass must exist, must be reachable without the VPN, and must be so conspicuous when used that nobody would use it casually.