Identity is the front door to everything else, so when it fails, everything behind it can appear to fail together.

The single front door problem

Before centralized sign-in, each application had its own door and its own lock. If one lock broke, one application was unavailable. Centralizing sign-in brought huge benefits: one place to enforce strong authentication, one place to remove a leaver, one place to see who signed in where. But it also created a single door in front of many rooms. When that door sticks, people cannot reach rooms that are perfectly healthy.

Why leaders underestimate it

• It rarely fails. Modern cloud identity services are built for high availability, so outages are uncommon, and people plan for what they have seen.
• It is invisible until it breaks. Nobody thinks about sign-in on a good day, so its place in every business process goes undocumented.
• The cause is often not the provider. Expired certificates, broken network rules, directory failures, and bad configuration changes made by your own staff cause many sign-in outages.
• The blast radius is wide. Even when applications work, nobody can reach them, and automated systems that rely on tokens may stop too.

What good planning buys you

A good continuity plan does not promise that nothing will ever fail. It makes sure that when sign-in fails, the most important work continues, the right people know what to do within minutes, emergency access exists without creating a permanent security weakness, and recovery is clean. The goal is not perfection. It is a short, calm, rehearsed response instead of a long, noisy, improvised one.

Continuity planning uses a handful of terms again and again. Learn them once and every later chapter becomes easier.

One distinction deserves emphasis because it is so often confused: the provider’s availability promise is not your recovery plan. A contract may promise very high uptime, and yet the minutes or hours when the service is down still matter to you. Your recovery goals come from what your business can tolerate, not from what the provider has promised.

“Okta is down” can mean many different things. Each has a different cause, a different symptom, and a different response.

The most important lesson in this table is that a large share of sign-in outages are in your own hands. A plan that only imagines a provider-wide failure will miss most of the real events. A good plan covers both: events you cannot prevent, where preparation limits the damage, and events you can prevent, where discipline avoids them in the first place.

flowchart TD
    OUT["Sign-in problem reported"] --> Q1{"Provider status page shows an incident?"}
    Q1 -- "Yes" --> P["Provider-side: follow degrade and communicate path"]
    Q1 -- "No" --> Q2{"Recent change by your team?"}
    Q2 -- "Yes" --> C["Likely configuration: revert the change"]
    Q2 -- "No" --> Q3{"Only one directory, site, or application?"}
    Q3 -- "Yes" --> L["Local dependency: directory, network, or application"]
    Q3 -- "No" --> X["Broader investigation: certificates, DNS, factors"]
    

You cannot plan for a dependency you do not know exists. The first practical task is to draw the map.

Layers of dependency

• People signing in to applications. The obvious layer: employees, contractors, and partners reaching business systems through single sign-on.
• Administrators. Staff who manage users, policies, and applications through the admin console and automation.
• Machines and integrations. Scripts, services, and tools that obtain tokens to call other systems.
• Provisioning. Automatic creation, update, and removal of accounts in applications when people join, move, or leave.
• Devices and networks. Laptop sign-in, wireless access, virtual private networks, and zero-trust gateways that ask the identity provider before letting traffic through.
• Other security tools. Monitoring and approval systems that depend on identity to know who did what.
• Customers. If you use Okta for customer sign-in, an outage reaches your revenue directly.

How to build the map

flowchart LR
    OK["Okta"] --> A1["Email and calendar"]
    OK --> A2["Chat and video"]
    OK --> A3["Ticketing"]
    OK --> A4["Payroll and HR"]
    OK --> A5["Code and deployment"]
    OK --> A6["VPN and network access"]
    OK --> A7["Admin console and automation"]
    A3 -.->|"Needed to manage the incident"| OK
    A2 -.->|"Needed to coordinate"| OK
    

A cloud identity service is run by the provider, but the way you use it is yours. Resilience is shared, and the split matters.

What the provider generally handles

• Operating the platform across multiple data centers, with redundancy designed to survive many kinds of hardware and facility failures.
• Monitoring the service, responding to incidents, and publishing status information.
• Applying updates, patches, and capacity changes.
• Offering contractual availability commitments, with remedies that are usually limited to service credits and not business losses.

What stays with you

• Your own configuration: policies, rules, application settings, and who can change them.
• The connections between Okta and your world: directories, agents, certificates, networks, and custom domains.
• Your applications’ behavior when sign-in is unavailable.
• Emergency access, communication, and the human process of responding.
• Knowing when the provider has a problem, and having your own monitoring.

The sensible reading is that the provider reduces the probability of the platform failing, and you reduce the consequence when anything fails. Reading the service terms, the published architecture and reliability information, and the status history gives you the facts. They also change, so recheck them on a schedule.

flowchart TD
    PR["Provider: platform, redundancy, status"] --> SH["Shared outcome: people can sign in"]
    YU["You: configuration, connections, fallback, people"] --> SH
    

A single sign-in crosses several components. Seeing each one explains why the same symptom can have many causes.

sequenceDiagram
    participant U as Person
    participant A as Application
    participant D as DNS and network
    participant O as Okta
    participant DR as On-premises directory
    participant F as Second factor
    U->>A: "Open application"
    A-->>U: "Redirect to sign-in"
    U->>D: "Resolve and connect"
    D->>O: "Secure connection"
    O->>DR: "Verify password through agent"
    DR-->>O: "Accepted"
    O->>F: "Request second factor"
    F-->>O: "Approved"
    O-->>A: "Signed result"
    A-->>U: "Session started"
    

Every arrow is a place where a failure could occur, and each failure has its own owner. When you write the plan, label each step with who owns it and what the fallback is. The step that most often surprises teams is the second factor, because people forget that a perfectly healthy platform is still useless if the codes never arrive.

Not every application deserves the same protection. Tiering the applications turns an overwhelming problem into a manageable list.

A simple tiering method

For each application, ask what the business loses per hour of unavailability, whether people or customers could be harmed, whether laws or contracts are affected, and whether the application is needed to run the incident response. Then group applications into a handful of tiers.

quadrantChart
    title Prioritizing applications for continuity effort
    x-axis Low harm if down --> High harm if down
    y-axis Easy to add fallback --> Hard to add fallback
    quadrant-1 Plan carefully with leadership
    quadrant-2 Accept or work around
    quadrant-3 Wait for recovery
    quadrant-4 Add fallback first
    Chat and incident tools: [0.8, 0.2]
    Clinical records: [0.95, 0.7]
    Order processing: [0.85, 0.4]
    Email: [0.6, 0.3]
    Learning platform: [0.1, 0.2]
    Legacy finance system: [0.65, 0.85]
    

The picture is a way of thinking, not a measurement. The upper-right corner, where harm is high and a fallback is hard to build, is where executives and architects need to sit together, because the answer may be to redesign the application, not to bolt on a workaround.

Recovery goals turn vague worry into numbers the business can agree with. They also reveal when current arrangements fall short.

Applying RTO and RPO to identity

The recovery time objective for sign-in asks how long people can be unable to sign in before the damage becomes unacceptable. The answer differs by group: a call center agent without access loses work every minute, a developer may tolerate an hour, and an employee on holiday does not care. The recovery point objective, applied to identity, asks how much recent change could be lost. Examples include the last configuration edits, newly created accounts, password changes, and enrollment of new second factors.

Questions that produce honest numbers

• If nobody could sign in for thirty minutes, what would happen? For four hours? For a full day?
• Which activities cannot wait, and who performs them?
• Which sign-ins are triggered by schedules, such as shift changes or month-end?
• Are there legal or contractual limits on downtime?
• What do customers experience, and what would they do?

These values are only examples. Your own numbers should come from your business, be approved by those who bear the consequences, and be reviewed at least yearly. If the numbers are tighter than what the current design can deliver, you have found a gap, and the plan’s job is to close it or to formally accept the risk.

gantt
    title Illustrative timeline of an outage and recovery goals
    dateFormat HH:mm
    axisFormat %H:%M
    section Outage
    Sign-in unavailable :crit, o1, 09:00, 150m
    section Response
    Detect and declare :r1, 09:00, 10m
    Switch incident team to emergency access :r2, 09:10, 10m
    Critical apps on local fallback :r3, 09:20, 30m
    section Goals
    Tier 1 target reached :milestone, 09:50, 0m
    Tier 2 target window :g2, 09:50, 120m
    

There is a range of ways to prepare, from doing nothing to running a complete second identity system. Each costs something and protects something.

Most organizations land on a layered mix: protect the essentials, give a handful of critical applications a controlled fallback, tune sessions sensibly, and keep offline procedures for safety-critical work. A full secondary identity provider is usually reserved for businesses where any sign-in outage is intolerable, and it deserves its own discussion later in this guide.

flowchart TD
    A["Layer 1: Resilient sessions and good monitoring"] --> B["Layer 2: Break-glass access for the response team"]
    B --> C["Layer 3: Controlled local fallback for critical applications"]
    C --> D["Layer 4: Offline procedures for safety-critical work"]
    D --> E["Layer 5 (optional): Secondary identity provider"]
    

Not everything stops at once. Understanding how sessions behave tells you who is affected immediately and who has time.

Two layers of session

When someone signs in, two kinds of memory are created. The identity provider remembers that the person signed in, which lets them open further applications without typing again. Each application also starts its own session, which it keeps for its own length of time. When the identity provider becomes unavailable, people already signed in to an application usually keep working until that application’s own session ends. People who have not signed in, or whose sessions expire, are blocked.

What this means during an outage

• Early in the day, many are stuck. A morning outage hits hardest, because everyone needs to sign in at once.
• Late in the day, fewer are stuck. An outage that begins in the afternoon may go unnoticed by people with live sessions.
• New joiners and password changes are blocked. Anything that needs the identity provider to act cannot be done.
• Machine tokens expire. Automated systems holding short-lived tokens stop when they next need a new one.
• Re-authentication prompts fail. Applications that ask for a fresh sign-in for sensitive actions cannot complete them.

The session length trade-off

There is no perfect answer. A common compromise is moderate lifetimes for most users, longer ones on managed devices in controlled places, and short lifetimes for privileged work. What matters is that the choice is deliberate and that the incident team knows roughly how long existing sessions will last.

stateDiagram-v2
    [*] --> SignedIn
    SignedIn --> Working: "application session active"
    Working --> Working: "within session lifetime, outage does not matter"
    Working --> Blocked: "session expires during outage"
    Blocked --> Working: "identity provider returns, sign in again"
    

A break-glass account is the key kept behind glass for emergencies. Done well it saves the day. Done badly it becomes the weakest door in the building.

What a break-glass account is for

It lets a small number of trusted people reach the administrative controls when normal sign-in cannot be used. Reasons include a faulty policy that blocks everyone including administrators, a failure of the second factor, or an outage in a connector that normal administrators rely on. It must work when things are broken, so it must not depend on the things most likely to be broken.

Design principles

• Few and named. Two or three accounts, not tens. Each is owned and assigned to a role, not to one person who might be on holiday.
• Independent of normal paths. Not subject to the policies that could lock everyone out. Excluded from rules that rely on the on-premises directory or a chat-delivered code.
• Very strong credentials. Long random passwords stored securely in separate custody, plus a hardware key kept in a safe where possible.
• Split knowledge. Two people each hold half, or two keys are needed, so no single person can use it casually.
• Loud when used. Any sign-in with the account triggers an immediate alert to several people and the security team.
• Used only in emergencies. Never for daily work, and after any use the credentials are replaced.
• Tested on a schedule. A quiet, planned test proves it works, followed by credential rotation.

flowchart TD
    E["Emergency declared"] --> A["Two authorized people retrieve credentials"]
    A --> S["Sign in with break-glass account"]
    S --> AL["Automatic alert to security and leadership"]
    S --> W["Perform only the planned emergency actions"]
    W --> R["Rotate credentials and record the use"]
    R --> RV["Post-incident review of what was done"]
    

The people who fix the problem need tools that survive the problem. Plan administrator access separately from user access.

What administrators need during an incident

• Access to the Okta admin console, or at minimum to the provider’s status information and support channel.
• Access to the change log, so they can see recent changes that might have caused the problem.
• The ability to revert a policy or rule, and to disable a faulty connector or factor.
• Access to the on-premises directory and the connector servers, through the network team and separate accounts.
• A way to talk to each other and to leadership that does not depend on sign-in.
• A way to contact the provider’s support, including phone numbers and customer identifiers stored outside the system.

Protecting administrator continuity

flowchart LR
    ADM["Administrator"] --> N1["Normal console sign-in"]
    ADM --> N2["Break-glass console sign-in"]
    ADM --> N3["Independent chat and phone bridge"]
    ADM --> N4["Printed and offline runbooks"]
    N1 --> FIX["Diagnose and fix"]
    N2 --> FIX
    N3 --> FIX
    N4 --> FIX
    

For the few applications where an hour of downtime is truly unacceptable, a controlled local sign-in path can keep work going.

The idea

Most applications that support single sign-on also keep, or can enable, their own local accounts. In normal times, those local accounts are disabled or unused, and everyone signs in through Okta. In an emergency, a limited set of people can use the application’s local sign-in to keep working. The challenge is doing this without creating a permanent back door that attackers can use.

Making it safe

• Limit who has local accounts. Only essential operators, not everyone.
• Keep them disabled until needed. A documented step turns them on and another turns them off.
• Use strong credentials. Unique long passwords or hardware keys, held in separate custody.
• Watch them. Alert on any local sign-in, in or out of an incident.
• Restrict by network. Allow emergency local sign-in only from controlled locations.
• Reduce rights. Local accounts should have the minimum needed to keep operations going.
• Test regularly. Prove that the account works and that the alert fires.

flowchart TD
    N["Normal day"] --> SSO["Single sign-on through Okta"]
    N --> LOC["Local accounts disabled and monitored"]
    EM["Emergency declared"] --> EN["Authorized lead enables local sign-in"]
    EN --> OP["Named operators sign in locally"]
    OP --> AL["Alerts and logging on every use"]
    RE["Okta restored"] --> DIS["Disable local sign-in and rotate credentials"]
    

Many companies keep passwords in an on-premises directory and let Okta pass sign-in through to it. That link is both a strength and a continuity risk.

How the dependency works

With a connection often called delegated authentication, Okta does not hold the password. It asks a small program inside your network, called an agent, to check it against the directory. If the agents or directory are down, Okta is healthy but the password check cannot be completed, and people from that directory cannot sign in. The reverse arrangement, where Okta stores a protected copy of the password, lets sign-in work even if the directory is unreachable, at the cost of holding a second copy.

Protecting the link

• Run at least two agents on separate servers and, where possible, in separate locations.
• Place them near healthy, well-replicated directory servers.
• Stagger patching so that both agents are never restarted together.
• Monitor agent connections and alert when fewer than two are connected.
• Decide whether a protected password copy in Okta is a better fit for critical populations.
• Make sure the service account used by agents does not expire or lock out.

flowchart LR
    OK["Okta"] --> AG1["Agent 1"]
    OK --> AG2["Agent 2"]
    AG1 --> DC1["Directory server A"]
    AG2 --> DC2["Directory server B"]
    DC1 --- DC2
    

Many sign-in outages are really second-factor outages. The platform is up, the password is right, and the code never arrives.

Why factors fail

• Message delivery. Text and voice codes depend on carriers and aggregators, which can be slow or fail for whole regions.
• Push notifications. They rely on the phone maker’s notification services and on the person having signal and the app installed.
• Lost, broken, or new phones. Large groups can lose their factor at once, such as after a phone upgrade campaign or a trip abroad.
• Hardware tokens. Batteries die and keys are forgotten at home.
• Enrollment gaps. People who never enrolled a second method have no fallback at all.

Building factor resilience

• Require every user to enroll more than one method, such as an app and a hardware key.
• Avoid depending on a single delivery channel for critical staff.
• Give administrators and critical operators at least two independent strong factors.
• Prepare a safe recovery path for people who lose all factors, with strong identity verification.
• Know how to temporarily change policy so that a failing factor is not required, and who may approve that change.
• Monitor delivery success and latency so you notice degradation before users complain.

flowchart TD
    A["User must prove a second factor"] --> B{"Primary factor works?"}
    B -- "Yes" --> OK["Signed in"]
    B -- "No" --> C{"Second enrolled factor works?"}
    C -- "Yes" --> OK
    C -- "No" --> D["Verified recovery process with help desk"]
    D --> OK
    

Many reported identity outages are network problems that only look like identity problems. Plan the path as carefully as the service.

The network dependencies

• Name resolution. If the sign-in address cannot be resolved, nothing else matters. Your own resolvers, split-horizon setups, and cached records are common culprits.
• Outbound allow lists. Firewalls and proxies must permit access to the provider’s addresses. Changes to those lists, especially when the provider adds new ranges, can silently block sign-in.
• Inspection devices. Equipment that opens secure traffic can break sign-in flows that depend on end-to-end checks.
• Connector paths. The agent servers need outbound access to Okta and internal access to directories.
• Remote workers. Home networks, mobile data, and public wireless each add their own quirks.
• Time synchronization. Signed messages carry times, and servers with wrong clocks reject good messages.

Practical protections

• Subscribe to the provider’s notices about address changes, and automate updates to allow lists where feasible.
• Keep at least two independent DNS resolvers for critical networks.
• Document the exception for the identity provider in inspection devices, and review it after every network change.
• Test sign-in from several network types: office, home, mobile, and guest wireless.

flowchart LR
    U["User device"] --> R["DNS resolvers"]
    U --> FW["Firewall and proxy"]
    FW --> O["Okta"]
    AG["Connector servers"] --> FW
    AG --> DIR["Directory"]
    

Expiry dates are the most preventable cause of identity outages. They are predictable, yet they keep catching teams by surprise.

The things that expire

• Custom domain certificates. If your sign-in page uses your own domain name, its certificate must be renewed, and in some setups you manage it yourself.
• Signing certificates for applications. Applications trust sign-in messages signed with a certificate. When it expires or is rotated, applications must learn the new one.
• Connector and service credentials. Agent registrations, service account passwords, and API tokens.
• Directory and network certificates. Used for secure directory connections and network devices.
• Client certificates. For devices or users who sign in with them.

A certificate discipline

gantt
    title Certificate renewal with overlap
    dateFormat YYYY-MM-DD
    axisFormat %b %d
    section Old certificate
    Valid period :a1, 2026-01-01, 90d
    section New certificate
    Prepare and add :b1, 2026-03-01, 14d
    Overlap period :b2, 2026-03-15, 17d
    Valid period :b3, 2026-04-01, 90d
    section Applications
    Update and test :c1, 2026-03-15, 14d
    

Sign-in is only part of what an identity platform does. It also creates, updates, and removes accounts, and that work does not stop mattering during an outage.

What can be delayed

• New joiners. People starting during an outage may be unable to receive their accounts or enroll factors.
• Role changes. Movers keep old access, or lack new access, until synchronization resumes.
• Group membership changes. Access granted by group may lag.
• Provisioning queues. Changes made just before or during the outage may be retried when service returns, sometimes in a burst.

What must not be delayed

• Leavers. Removing access for departing staff is a security matter that cannot wait for the platform to return. See the next chapter.
• Emergency access changes. Granting or removing rights for incident responders.

Planning actions

• Know how to see the backlog of pending provisioning actions when service returns.
• Have a manual process for joiners in the first days of an outage, such as issuing temporary access in the few applications that matter most.
• Pause automated bulk changes during an incident, so a stale or partial feed does not cause damage.
• After recovery, reconcile accounts against the HR source for the outage window.

sequenceDiagram
    participant HR as HR system
    participant OK as Okta
    participant APP as Application
    HR->>OK: "New joiner event"
    Note over OK: "Outage begins, queue holds the action"
    OK--xAPP: "Account creation cannot be delivered"
    Note over OK: "Service restored"
    OK->>APP: "Queued creation retried"
    APP-->>OK: "Account created"
    

An outage is a stressful, distracting time, which makes it a favorite moment for both mistakes and attacks.

Risks to plan for

• Delayed revocation. If a person is dismissed during an outage and access cannot be removed centrally, they may keep working in applications.
• Pressure to loosen controls. Leaders under stress may ask to switch off strong authentication broadly.
• Phishing in the confusion. Attackers send fake notices such as “sign-in is down, use this link”, exploiting the noise.
• Social engineering of the help desk. Callers claim to be locked out and need urgent access.
• Abuse of fallback paths. Local accounts and break-glass credentials become attractive targets.
• Gaps in logging. Monitoring that depends on identity data may be blind or incomplete.

Defenses

flowchart TD
    OUT["Outage in progress"] --> R1["Leaver list checked daily"]
    OUT --> R2["Official channel only for instructions"]
    OUT --> R3["Strict help desk verification"]
    OUT --> R4["Fallback accounts alerted and time-limited"]
    OUT --> R5["Independent log review"]
    

During an outage, silence is worse than bad news. A good communication plan keeps people informed, calm, and safe.

Audiences and what each needs

Principles of good updates

• Say what you know, what you do not know, and when the next update will come. Even “no change, next update in thirty minutes” is valuable.
• Be plain. Staff do not need the technical cause. They need to know what they can still do.
• One voice. A single person owns external wording, so messages do not contradict one another.
• Use prepared templates. Write them in advance for start, update, workaround, and resolution.
• Warn about scams. Include the official channels in each message.

sequenceDiagram
    participant IC as Incident commander
    participant CL as Communications lead
    participant S as Staff
    participant E as Executives
    IC->>CL: "Facts and expected next steps"
    CL->>S: "Update: what is affected and what to do"
    CL->>E: "Impact and decisions needed"
    Note over CL: "Next update scheduled"
    

Confusion costs more time than most technical problems. Clear roles let a team of ordinary people work like a crew.

Rules that keep the team effective

• Roles are assigned at the start of the incident and announced to the team.
• Everyone has a backup, because the person in the role may be asleep or unreachable.
• The commander calls a short check-in at set intervals, and everyone else focuses between them.
• Handovers are explicit when people tire, and the scribe’s log supports them.
• Decisions with security or business impact have a named approver.

flowchart TD
    IC["Incident commander"] --> TL["Technical lead"]
    IC --> CM["Communications lead"]
    IC --> SC["Security lead"]
    IC --> HD["Help desk lead"]
    IC --> SB["Scribe"]
    IC --> BL["Business liaisons"]
    

The first hour of an outage is shortened or lengthened by one thing: how quickly you know. Your own monitoring should tell you before your users do.

Signals worth watching

Monitor from outside

If your monitoring runs inside the same network and depends on the same sign-in, it may fail together with the thing it watches. Run at least one synthetic check from outside your network, on infrastructure that does not require Okta, and send alerts to a channel that does not depend on it.

flowchart LR
    SYN["Synthetic test from outside"] --> AL["Alert router"]
    ST["Provider status feed"] --> AL
    LG["Sign-in failure rate"] --> AL
    CN["Connector status"] --> AL
    HD["Help desk ticket spike"] --> AL
    AL --> ON["On-call phone and independent chat"]
    

The hardest moment in an outage is deciding when to stop waiting and start acting. A pre-agreed framework removes the argument.

The three postures

• Wait and watch. The impact is small or the provider gives a credible short estimate. The team monitors and communicates.
• Degrade deliberately. The impact is significant. The team protects the essentials, enables local fallbacks for critical applications, and tells staff which functions are unavailable.
• Fail over fully. The impact is severe and prolonged. The team invokes the secondary arrangements, if any exist, such as an alternate identity path for the most critical groups.

Triggers worth writing down

flowchart TD
    D["Detection"] --> Q1{"Our own recent change?"}
    Q1 -- "Yes" --> RV["Revert change and verify"]
    Q1 -- "No" --> Q2{"Critical operations blocked?"}
    Q2 -- "No" --> W["Wait and watch, update staff on a schedule"]
    Q2 -- "Yes" --> Q3{"Provider estimate short and credible?"}
    Q3 -- "Yes" --> DG["Degrade: protect essentials, enable selected fallbacks"]
    Q3 -- "No" --> FO["Fail over: invoke secondary arrangements and manual procedures"]
    

The first minutes shape the whole incident. A short, practiced checklist keeps people from skipping essential steps under stress.

stateDiagram-v2
    [*] --> Detected
    Detected --> Sorted: "check status and recent changes"
    Sorted --> Declared: "open incident and assemble team"
    Declared --> Informed: "first message sent"
    Informed --> Stabilizing: "essentials protected, fallbacks assessed"
    Stabilizing --> [*]
    

When service returns, the work is not over. The return itself can cause trouble, and the outage leaves data behind that must be checked.

The return to normal

• Confirm recovery with real tests. Sign in as several different kinds of users, from several networks, to several applications, with the factors people actually use.
• Expect a surge. Everyone who was blocked tries again at once, and the second-factor channel and the help desk may be overloaded.
• Turn off fallbacks in order. Disable local emergency accounts and exceptions, rotate their credentials, and confirm that normal paths work.
• Reverse temporary policy exceptions. Make sure every relaxed rule is restored, with a checklist and a second pair of eyes.
• Release paused jobs carefully. Restart automation and bulk changes only after checking that data is consistent.

Reconciliation checklist

flowchart TD
    R["Service returns"] --> T["Test with real users and networks"]
    T --> F["Disable fallbacks and rotate credentials"]
    F --> P["Restore policies and exceptions"]
    P --> Q["Release paused jobs"]
    Q --> C["Reconcile accounts and logs"]
    C --> V["Declare recovered and schedule review"]
    

The most expensive continuity option is a second system that can authenticate people if the first fails. It is worth understanding why people choose it and why many do not.

What it would involve

• A second identity provider holding enough user information to authenticate people.
• A method to keep both in step: users, groups, credentials, and second factors.
• A way for applications to trust either provider and switch between them.
• Policies equivalent in strength, so that failing over does not weaken security.
• Regular testing, since an untested standby is a wish.

A lighter alternative: a narrow standby

A common compromise is a small standby for the most critical groups and applications only: a handful of operators, with a limited set of applications that can accept an alternate path. This delivers most of the benefit at a small fraction of the cost, and it can be tested more easily.

flowchart LR
    U["Critical operators"] --> P1["Primary: Okta"]
    U -.->|"Failover only"| P2["Narrow standby path"]
    P1 --> A["Critical applications"]
    P2 --> A
    

If Okta also signs in your customers, an outage is not just an internal inconvenience. It is lost revenue and damaged trust.

How customer impact differs

• Customers cannot be briefed in advance. They have no runbook and no patience, and they leave.
• Scale and timing are unpredictable. Traffic can spike with a campaign, a launch, or a seasonal event.
• Existing sessions matter more. Long, safe sessions let customers keep shopping or working while sign-in is down.
• Guest paths may be possible. Some actions, such as browsing or paying as a guest, can proceed without a login.
• Reputational harm. Public outages may be reported publicly, and customers expect clear statements.

Design choices that help

flowchart TD
    C["Customer opens the app"] --> S{"Existing session valid?"}
    S -- "Yes" --> OK["Continue as normal"]
    S -- "No" --> L{"Sign-in available?"}
    L -- "Yes" --> SI["Sign in"]
    L -- "No" --> G{"Guest path available for this action?"}
    G -- "Yes" --> GU["Continue as guest"]
    G -- "No" --> MS["Clear message and retry guidance"]
    

A plan that has never been tested is a hope written down. Regular exercises turn it into a skill.

Kinds of exercises

Scenarios worth rehearsing

• A provider-wide disruption starting at nine on a Monday morning.
• A bad policy change that blocks every user, including administrators.
• An expired certificate on the custom sign-in domain.
• A failure of text message delivery for a whole region.
• Loss of both connector servers for the main directory.
• A leaver dismissed on the first day of an outage.
• A phishing campaign that exploits a public outage.

flowchart LR
    EX["Exercise"] --> OB["Observations"]
    OB --> GA["Gaps and actions"]
    GA --> UP["Updated plan"]
    UP --> EX
    

Plans decay. People change roles, applications are added, and contacts go stale. Governance is what keeps a plan useful a year later.

What good governance includes

• A named owner. One person is accountable for the identity continuity plan, with a deputy.
• An executive sponsor. Someone senior who can approve risk acceptance and funding.
• A change trigger. New applications, mergers, and new regions trigger a review of the plan, not just a yearly calendar entry.
• Application onboarding questions. Every new application answers the continuity questions before launch: tier, fallback, and owner.
• Metrics. Time to detect, time to declare, time to restore, exercise results, and open actions.
• Review after every event. Real incidents and near misses are examined without blame, and lessons are tracked to completion.
• Documents that are findable. The plan is stored in more than one place, printed for key roles, and tested for access.

flowchart LR
    OW["Plan owner"] --> PL["Plan and runbooks"]
    SP["Executive sponsor"] --> OW
    PL --> EXC["Exercises"]
    PL --> INC["Real incidents"]
    EXC --> LN["Lessons"]
    INC --> LN
    LN --> PL
    

These approaches have repeatedly proved their worth in organizations that depend heavily on a central identity provider. Adapt them to your own size and risk.

flowchart TD
    A["Know dependencies and tiers"] --> B["Protect responders"]
    B --> C["Fallbacks for Tier 1"]
    C --> D["Redundant factors, agents, resolvers"]
    D --> E["Monitor from outside"]
    E --> F["Pre-approved exceptions and roles"]
    F --> G["Regular practice"]
    G --> A
    

These habits look like preparation but fail when they are needed. Spot them early.

Every continuity measure buys safety at some price. Naming the trade-offs lets leaders choose with open eyes.

The main trade-offs

Best practices

• Map every dependency on Okta, including the incident tools and the machines.
• Tier applications by harm and set recovery objectives with the business.
• Keep the response team independent of the system that failed.
• Design a small number of break-glass accounts with split custody, alerts, and tests.
• Give Tier 1 applications a switch-on local fallback with named operators.
• Use redundant agents, factors, and resolvers, and monitor each.
• Run an external synthetic sign-in and subscribe to the provider status feed.
• Prepare communication templates and independent channels.
• Pre-approve narrow exceptions and the people who may grant them.
• Keep certificates in an inventory with owners and alerts.
• Exercise regularly and fix the gaps the exercises reveal.

Common mistakes

• Confusing the provider’s uptime promise with your own recovery plan.
• Planning only for a provider-wide failure and ignoring your own configuration mistakes.
• Storing break-glass credentials in a system that needs the failed service.
• Leaving temporary exceptions in place after recovery.
• Forgetting leavers and security checks while busy with the outage.
• Skipping the review after a near miss because nothing bad happened.
• Letting the plan owner leave without a handover.

quadrantChart
    title Matching continuity investment to risk
    x-axis Low business impact --> High business impact
    y-axis Low likelihood --> High likelihood
    quadrant-1 Invest heavily and practice often
    quadrant-2 Prevent and monitor
    quadrant-3 Accept and document
    quadrant-4 Prepare standby and drill
    Own policy mistake: [0.6, 0.8]
    Certificate expiry: [0.7, 0.7]
    Second-factor delivery delay: [0.5, 0.6]
    Directory connector failure: [0.6, 0.5]
    Provider-wide disruption: [0.9, 0.2]
    Regional provider fault: [0.7, 0.25]
    

The picture shows an idea, not data from your organization. Frequent causes within your own control, such as policy mistakes and certificate expiry, are best prevented and monitored. Rare, severe events, such as a provider-wide disruption, are best met with a prepared and rehearsed response, because you cannot stop them from happening.

Continuity spending competes with other needs. A clear business case makes the choice a rational one.

Estimating the cost of an outage

• Lost productivity. Number of blocked staff multiplied by hours and by the average cost of an hour of their work.
• Lost revenue. Sales or services that cannot be delivered during the outage.
• Direct incident cost. Overtime, contractors, and emergency support.
• Contract penalties and compensation. Payments owed to customers or partners.
• Regulatory consequences. Reporting duties and potential fines in regulated industries.
• Reputation. Harder to count, yet real, especially for customer-facing outages.

Estimating the cost of preparation

The pattern in this table is encouraging. The measures that bring the greatest protection, such as protecting responders, break-glass, monitoring, and practice, are also the cheapest. The expensive items are reserved for the systems where the cost of an outage is highest. A leader looking at the table can fund the inexpensive core at once and weigh the larger items against the estimated cost of downtime.

flowchart LR
    CO["Estimated cost of outage per hour"] --> CMP{"Compare"}
    CP["Annual cost of preparation"] --> CMP
    CMP --> DEC["Fund core measures, weigh the larger ones against risk"]
    

To bring everything together, here is an invented company and its continuity plan. The company, numbers, and names are made up for teaching.

The company

Meridian Freight is a fictional logistics company with 14,000 employees across three continents. It runs warehouses around the clock, a dispatch center, a customer portal, and a corporate office. Okta signs in every employee, and the customer portal uses it for business customers. In the past year, a bad policy change blocked all administrators for forty minutes, and an expired certificate on the custom sign-in domain caused a two-hour warehouse outage. Leadership asked for a proper plan.

The plan

flowchart TD
    DET["External synthetic test fails"] --> PH["On-call phone alert"]
    PH --> IC["Incident commander opens bridge"]
    IC --> RS["Responders use break-glass if needed"]
    IC --> T1["Tier 1 owners enable local fallback"]
    IC --> CM["Communications lead updates staff every 30 minutes"]
    T1 --> WH["Warehouses and dispatch continue"]
    

How the first year went

In the first quarterly break-glass test, the team discovered that one of the three accounts had a hardware key that no longer worked, and that the second custodian had left the company. Both were fixed within a week. During the first tabletop, the group realized the incident chat tool itself used Okta for sign-in, which led to the purchase of an independent alternative. The first game day exposed that the warehouse manager’s phone number in the contact list was a decade old.

In month seven, a second-factor message delivery problem delayed codes for staff in one region for ninety minutes. The external test did not catch it, because it used an app-based factor, but the help desk ticket spike alerted the team in under ten minutes. A narrow, approved exception let supervisors in that region use their hardware keys instead, and normal operation returned without any global weakening of security. In month ten, a certificate alert at thirty days led to a calm renewal with no user impact. Leadership noted that the same events a year earlier had cost hours and money.

Short answers to questions that come up often. Okta’s features, service terms, and limits change over time, and some depend on your plan, so confirm exact details in your contract and the current Okta documentation.

Planning for an identity outage means keeping the right people and the right systems working when the front door sticks.