Start with the idea, then add the details.

Okta is a service that keeps a list of the people in your organization and decides who may open which work apps. Each person on that list is a user, and each user has a status, which is a label that says what state the account is in right now. Active means the person can sign in. Other statuses mean other things. Suspend and Deactivate are two actions that move a user into a state where they can no longer sign in.

Suspend is a pause. The person cannot sign in, but Okta keeps almost everything about them in place: their profile, their groups and their app assignments. When you later press Unsuspend, the person comes back as they were. Deactivate is an ending. The person cannot sign in, and Okta starts removing the things that connect them to your apps. If you bring them back, they come back as a fresh start that needs to be set up again.

To understand the cure, look at the illness first.

People do not stay the same forever

A workforce is always changing. New people arrive, others move teams, some leave for a while and some leave for good. Each change means the list of who may open which app must change as well. If the list is not updated, former staff can still read private files, or a person on leave can be hacked while nobody is watching their account.

One switch is not enough

If there were only one way to switch off access, organizations would face a hard choice. Either they would destroy a person’s whole setup every time someone took a break, or they would leave the setup lying around forever after someone left. Neither is good. Okta gives two different tools so that the tool can fit the situation.

What goes wrong without the right tool

• A person returns from leave and finds that all their app access is gone, which wastes days of help desk time.
• A person who left months ago still counts toward the company’s license bill.
• A suspended account is forgotten, and nobody notices that it was never closed for good.
• An investigation needs the account frozen but intact, and deactivation destroys useful evidence.

Every account travels through a set of states, like a person walking through rooms in a house.

A user in Okta is never just “there” or “not there”. It is always in one of several named states. A life cycle is the full set of states and the allowed moves between them. Knowing the life cycle makes it easy to see where Suspend and Deactivate fit.

stateDiagram-v2
  [*] --> Staged
  Staged --> Provisioned: Activate
  Provisioned --> Active: User finishes setup
  Active --> Suspended: Suspend
  Suspended --> Active: Unsuspend
  Active --> Deactivated: Deactivate
  Suspended --> Deactivated: Deactivate
  Provisioned --> Deactivated: Deactivate
  Deactivated --> Provisioned: Reactivate
  Deactivated --> [*]: Delete

Notice the shapes in the picture. Suspend sits on a small loop: you can go to Suspended and return to Active. Deactivate leads toward the exit. From Deactivated you can only go back through a fresh start, or leave for good by deleting the account.

One table that holds the heart of this whole guide.

How to read the table

Look at the rows where the two columns differ. Those rows are where mistakes happen. Both actions stop sign-in, so the first row looks the same. The real difference is what each action leaves behind, and how much work is needed to bring the person back. Keep this table in mind as you read the rest of the guide, because every later chapter explains one row in more depth.

Twelve small ideas that explain everything else.

The pause button, step by step.

When an administrator suspends a user, Okta changes the user’s status to Suspended. From that moment the person cannot sign in to Okta, and so cannot reach any app through Okta. Okta also clears the person’s active sessions, so a person who was signed in is signed out, in the places that depend on Okta for their sign-in.

What is kept

• The profile and all its fields.
• Group memberships, and the access that groups give.
• App assignments and the person’s records inside Okta.
• Enrolled sign-in methods, such as Okta Verify, in most cases.

The ending, step by step.

When an administrator deactivates a user, Okta changes the status to Deactivated, which is sometimes shown as Deprovisioned. The person can no longer sign in. In addition, Okta begins cleaning up. It removes the person’s app assignments and, for apps that have provisioning turned on, sends a message telling each app to deactivate or remove the person’s account there.

The road back is very different for each.

Unsuspend: pressing play

To undo a suspension, an administrator chooses Unsuspend. The user returns to Active. Because the profile, groups and app assignments were never removed, the person can sign in and find their app tiles where they left them. Usually no other work is needed.

Reactivate: starting again

To bring back a deactivated user, an administrator chooses Reactivate. This does not return the user to Active at once. Instead, the account moves back to an earlier state, such as Provisioned, and the person typically receives a new activation message and must set up their sign-in again. Because app assignments were removed during deactivation, they must be added again, either by hand or by rules that depend on groups and profile values.

There is a third step after Deactivate, and it cannot be undone.

A deactivated user is not gone. The record remains in Okta so that it can be reactivated or looked at later. To remove it entirely, an administrator performs a delete. In Okta’s design, you cannot delete a user directly from Active or Suspended. The user must be deactivated first, and then deleted. This extra step protects against mistakes.

Why not delete straight away?

• People sometimes return, and recreating them is painful.
• Records may be needed for audits, investigations or legal requests.
• The deactivated record keeps the username reserved so that it is not reused by mistake.
• Ownership of work, such as files or tickets, may need to be moved first.

The moving parts that sit around a single click.

The Suspend or Deactivate button is only the visible tip. Behind it sit several parts that work together. Knowing them helps you understand where things can go wrong.

flowchart LR
  A["Administrator or Automation"] --> API["Okta Lifecycle Service"]
  API --> UD["Universal Directory: User Records"]
  API --> SS["Session and Token Service"]
  API --> AA["App Assignments"]
  AA --> PR["Provisioning Engine"]
  PR --> APP1["Connected App 1"]
  PR --> APP2["Connected App 2"]
  API --> LOG["System Log"]
  SRC["HR System or Directory"] --> UD

Follow one suspension from the click to the final record.

Let us walk through what happens inside Okta when an administrator suspends a user. The names of the internal parts are simplified, but the order of events is the important lesson.

sequenceDiagram
  autonumber
  participant A as Administrator
  participant L as Lifecycle Service
  participant D as User Directory
  participant S as Session Service
  participant G as System Log
  A->>L: Request to suspend the user
  L->>L: Check the administrator is allowed
  L->>D: Change status from Active to Suspended
  D-->>L: Status saved
  L->>S: End all sessions for this user
  S-->>L: Sessions closed
  L->>G: Write a suspend event
  L-->>A: Done

Reading the picture

Step two matters more than it looks. Okta first checks whether the person asking is allowed to do this. A help desk worker, for example, may have the right to reset passwords but not the right to suspend people. Step three is the heart of the action: a single field, the status, changes from Active to Suspended. Step five ends the sessions, so that a person who was already signed in is pushed out. Step seven writes the diary entry.

What does not happen

• No app assignment is removed.
• No group membership is removed.
• Connected apps are normally not told to delete anything.
• The profile is not changed.

This is why suspension is quick and safe to undo. The system makes one core change and cleans up only the sessions.

A longer chain of events, because more is being undone.

sequenceDiagram
  autonumber
  participant A as Administrator
  participant L as Lifecycle Service
  participant D as User Directory
  participant S as Session Service
  participant P as Provisioning Engine
  participant X as Connected App
  participant G as System Log
  A->>L: Request to deactivate the user
  L->>L: Check permission
  L->>D: Change status to Deactivated
  L->>S: End all sessions
  L->>D: Remove app assignments
  D->>P: Notify about removed assignments
  P->>X: Ask the app to deactivate the user
  X-->>P: Confirm or report an error
  P->>G: Record the outcome
  L->>G: Write a deactivate event
  L-->>A: Done

Why this chain is longer

Deactivation touches the outside world. In step six, Okta sends a message to a connected app, and that app may answer slowly, say no, or be offline. Because of this, a deactivation can succeed in Okta while a downstream cleanup still shows an error that needs attention. Always look at the outcome of each connected app, not only the status in Okta.

The most misunderstood part of the whole topic.

When a person signs in, they receive a session in Okta and often separate sessions inside each app. A session is like a wristband at a theme park. Once the wristband is on, the staff at each ride look at the wristband, not at your ticket again.

What Okta can end

Okta can end the person’s Okta session when they are suspended or deactivated. The next time that person returns to Okta, for example to open a new app, they are refused.

What Okta may not end

Apps that have already accepted the person may keep their own sessions for minutes, hours or days. Some apps hold tokens, which are signed passes that remain valid until they expire. If the person is already inside, those apps may not check with Okta again until the pass runs out.

What stays and what goes, and why it matters.

Groups

Groups give many people the same access in one step. A suspended user normally stays in their groups. This is helpful, because on return the person is automatically back in everything. A deactivated user is removed from active use, and when they return you should check group membership carefully, since rules that depended on the profile may need to run again.

App assignments

An app assignment can come from a group, which is a group assignment, or be set directly on the person, which is a direct assignment. On deactivation, direct assignments are removed, and group-based ones stop applying because the account is no longer active. On suspension both are left alone.

Administrator roles

If the person holds an administrator role, a suspended account cannot use it, since the person cannot sign in. Still, remember to review and remove admin roles during an offboarding, so that the role does not return along with the account.

Where the real difference shows up outside Okta.

Many apps keep their own list of users. For these, Okta can act as the manager that creates and updates accounts, and removes them when the person leaves. This is called provisioning. Common ways to do it include a standard called SCIM, which is a shared language that apps use for user lists, and special connectors built for particular apps.

What each action means for a provisioned app

• Suspend: The app account normally stays as it is. The person cannot reach it through Okta, but the account still exists in the app. Some setups can be tuned to also disable the account, so confirm your settings.
• Deactivate: Okta sends a deactivate or delete message to the app, depending on its settings. The person’s account in the app is switched off or removed.
• Reactivate: Okta may need to create the account again, or turn it back on.

Settings to check for each app

When another system owns the person, Okta must follow its lead.

Many companies keep their people in a directory such as Active Directory or LDAP, and Okta imports them. Such users have a master: the directory is the source of truth, and it is the place where changes should be made.

Why this matters

If a user comes from a directory and you suspend them only in Okta, the next import may change their status again, depending on your settings. If the directory still says the person is enabled, a later sync might restore access you meant to block. The safe habit is to apply the change in the master system, and let Okta follow.

Letting the human resources system push the button.

Many organizations connect Okta to an HR system. When HR records a hire, a leave or a termination, Okta follows. This removes delays and mistakes, because people do not need to remember to open a ticket.

Why dates matter

HR data often carries an end date. A termination that takes effect at five in the evening should switch access off at five, not at midnight, and not three days later when someone remembers. Work with time zones in mind, so that people in different countries are treated on the right day.

Keeping accounts alive can cost real money.

Okta and many connected apps charge by the number of users. How a status counts toward a bill depends on your contract and on each app. As a general idea, active users count, and fully removed ones do not. The exact treatment of suspended and deactivated users can differ from product to product, so do not guess. Check your own agreement.

Where the money leaks

• A suspended account in a connected app may still hold a paid seat there, since the app was never told to remove it.
• Long suspensions that nobody reviews can cost for months.
• Deactivated users in Okta may free a seat in Okta, but only a cleanup message frees the seat in the connected app.

Powerful buttons need careful hands.

Not everyone should be able to switch off a person. Okta uses administrator roles, which are sets of permissions. Some roles can manage users in a limited set of groups, and others can manage everyone. The best practice is least privilege: give each person only the power they need.

Good patterns

• Help desk staff may unlock accounts and reset passwords, but cannot deactivate.
• Group administrators may manage users in their own departments only.
• Only a small, trusted team may deactivate and delete.
• Delete is separated from deactivate, so that two steps and often two people are involved.

A simple path to the right button.

flowchart TD
  S["Someone must lose access"] --> Q1{"Will they come back?"}
  Q1 -- "Yes, soon" --> SUS["Suspend"]
  Q1 -- "No" --> Q2{"Need evidence kept intact?"}
  Q1 -- "Not sure" --> SUS
  Q2 -- "Yes, for a short time" --> SUS2["Suspend, then review"]
  Q2 -- "No" --> DEA["Deactivate"]
  SUS2 --> DEA
  DEA --> Q3{"Retention period over?"}
  Q3 -- "Yes" --> DEL["Delete"]
  Q3 -- "No" --> WAIT["Keep the deactivated record"]

The rule of thumb

When in doubt, suspend first. Suspension is easy to undo, while deactivation starts removing things. You can always deactivate later, but you cannot easily put back what deactivation removed. At the same time, set a deadline for the doubt to end, so that a temporary pause does not become a permanent habit.

Four short stories that show the choices in action.

Story one: a long leave

Story two: a resignation

Story three: a suspected break-in

Security staff notice odd sign-ins from another country. They suspend the account at once, which stops the attacker and keeps the evidence. Then they revoke tokens, reset the credentials, check logs, and unsuspend only when it is safe.

Story four: a contractor

A contractor’s access should end when the contract ends. The account is created with an end date, and an automated job deactivates it on that date. No one has to remember.

Humans forget. Machines follow the plan.

Clicking in the admin screen works for one-off cases. For larger organizations, the same actions are triggered by software. There are three common ways.

What a good automation does

• Runs on a clear trigger, such as an HR end date or a security alert.
• Checks that the right person is selected before acting.
• Records why it acted, who or what asked it to, and when.
• Notifies the manager and the security team.
• Handles errors, and tells a human if a step fails.
• Can be paused if something looks wrong.

Common automation ideas

• Suspend any account that has been idle for a long time, then deactivate it if nobody objects.
• Suspend a user automatically when a high-risk alert fires.
• Deactivate contractors on the date their contract ends.
• Send a reminder before a long suspension ends.

Follow one account from birth to retirement.

flowchart LR
  H["HR or Directory Event"] --> C["Create Account"]
  C --> A["Active"]
  A -- "Pause" --> S["Suspended"]
  S -- "Return" --> A
  A -- "Departure" --> D["Deactivated"]
  S -- "Departure confirmed" --> D
  D -- "Retention period ends" --> X["Deleted"]
  D -- "Rehire" --> R["Reactivated"]
  R --> A

What data moves at each step

Read this table from top to bottom and you can see data slowly draining away. This draining is by design. Each step removes more, which is why each step is harder to undo than the one before.

Every choice gives something and costs something.

Suspend

Deactivate

The main trade-off

The trade-off is speed of return against thoroughness of cleanup. Suspend favors a quick return. Deactivate favors a clean break. Neither is better in itself. The right choice follows the facts of the case.

Several other tools can look like Suspend, but they have different jobs.

A key difference: who decides

A lock-out is a safety response by Okta itself, triggered by too many failed sign-ins. A suspension is a human or automated decision that this person must not sign in. The first is about suspected guessing. The second is about a business reason.

The point of these actions is safety, so they deserve a security look of their own.

Threats and defenses

Honesty about limits keeps people safe.

Suspend and Deactivate control sign-in through Okta. They are strong tools within that boundary, but the boundary is not the whole world. Several kinds of access can survive both actions.

Auditors love records, and these actions create many.

Many rules and standards ask organizations to prove that former staff lose access quickly, that dormant accounts are controlled, and that records are kept for a fixed time. Suspend and Deactivate help meet these demands, if they are used in a disciplined way.

What an auditor may ask

• How fast does access end after someone leaves?
• Who may suspend, deactivate and delete, and how do you know?
• Show every deactivation in the past quarter, and who did it.
• How long are suspended accounts allowed to stay suspended?
• When are records deleted, and under what rule?
• How do you stop the same person from being brought back without approval?

What helps you answer

What can go wrong, and how to be ready.

Common ways things break

• Okta accepts the action, but a connected app is offline, and the cleanup fails.
• A rate limit slows a large batch, so the end of the list is processed late.
• An automation runs twice and tries to act on a user who is already suspended or deactivated.
• A directory sync undoes a change.
• The person who must approve is on holiday, and the action waits.

How to make it dependable

What changes when you must act on thousands of people.

For one user, both actions feel instant. For thousands of users, other limits appear. Okta limits how many requests a program may send in a time window, to protect the service. Connected apps have limits too.

Large-scale cases

• A company closes a site and removes five hundred contractors on one day.
• A merger reorganizes thousands of accounts.
• A cleanup job deactivates every account unused for a year.

Good habits

You cannot manage what you cannot see.

Okta’s system log records events. Every suspend, unsuspend, deactivate, reactivate and delete leaves a line in it, together with who did it, when, and from where. You can search it, send it to a central monitoring tool, and set alerts.

flowchart LR
  E["Lifecycle Action"] --> L["Okta System Log"]
  L --> F["Log Stream or Export"]
  F --> M["Monitoring or SIEM Tool"]
  M --> AL["Alerts"]
  M --> DB["Dashboards and Reports"]
  AL --> H["Security or IT Team"]

Events worth watching

Useful metrics

Symptoms, likely causes and first fixes.

A calm way to investigate

Habits that work well, and habits that cause trouble.

Patterns that work

Anti-patterns that cause trouble

A short checklist you can print.

Best practices

• Write down which situations lead to Suspend, which to Deactivate and which to Delete.
• Set a review date every time you suspend someone.
• Use HR or the directory as the source of truth where possible.
• Test deactivation on every important connected app.
• Revoke tokens and end app sessions in urgent cases.
• Remove admin roles during offboarding.
• Limit who may deactivate and delete, and alert on large changes.
• Send the system log to central monitoring.
• Keep an offboarding checklist that goes beyond Okta.
• Agree on a retention period with legal and compliance teams.
• Review the suspended list every month.
• Practice the process with a test user before an emergency.

Common mistakes

Where these choices show up in working life.

The scenarios below are typical examples of how different fields apply these ideas. They are general descriptions, not accounts of any named company.

What these examples share

In every case the team decided the rule before the event, used automation for the routine part, kept humans in charge of exceptions, and checked the results afterward. The buttons are the same. The discipline around them makes the difference.

A person’s proof of identity does not vanish when the status changes.

Each person may have enrolled several ways to prove who they are: a password, a phone app, a security key, a fingerprint on a registered device. Together these are called authenticators. A natural question is what happens to them when a user is suspended or deactivated.

During suspension

Authenticators are normally left alone. They are simply not accepted, because the account itself is blocked. When the person returns, they can usually use the same phone app or key without enrolling again. This is another reason why a suspension leads to such a smooth return.

During deactivation

After deactivation, the account is no longer usable, and on reactivation the person is expected to go through setup again. Treat old enrollments with suspicion. A phone that was registered a year ago may have been replaced, lost or sold. Ask the person to set up fresh methods, and remove any that are no longer trusted.

A person leaves, but their work must stay.

Accounts do not only open doors. They also own things: documents, calendar invitations, scheduled jobs, shared folders and tickets. When an account is deactivated and later deleted, those things may be lost or left with no owner. A careful team plans the handover before the switch is thrown.

Why suspension helps here

Suspension gives you a safe waiting room. Access is blocked, yet the account and its files still exist. Administrators can then move ownership and copy data in a calm way, before the final step of deactivation.

When minutes matter, a written plan beats clever thinking.

Imagine an alert says a staff member’s account is being used by a stranger. People are rushed and tired, and mistakes are likely. A playbook is a short list of steps prepared in advance and practiced, so the team can act fast without improvising.

Decide once, so that you do not argue every time.

A lifecycle policy is a short written document that says which situations lead to which action, who may approve it, and how fast it must happen. With a policy, each case becomes a lookup, not a debate.

Questions the policy should answer

• Which events lead to Suspend, and for how long may a suspension last?
• Which events lead to Deactivate, and how soon after the event?
• How long are deactivated records kept before deletion?
• Who may perform and approve each action?
• What extra steps follow outside Okta?
• Who is told, and how?
• How are exceptions requested and recorded?

A sample layout

The numbers in this table are only an example. Your own rules depend on your laws, contracts and risks. Ask your legal and security teams to help set them.

Technology is only half of an offboarding. The other half is communication.

When access is switched off, people are affected: the person, their manager, their team, and sometimes customers. A plain, kind message prevents confusion and rumors.

Privacy matters

Do not share the reason for a suspension with more people than needed. A suspension may be about health, a family event, or an investigation. Sharing too much can cause harm and may break privacy rules.

Practice on a dummy before you need it on a real person.

Lifecycle actions touch many systems, so surprises are common. The cheapest way to find them is to rehearse with a test account in a safe environment.

A rehearsal plan

Most organizations already have old suspended and forgotten accounts.

If you have used Okta for years, there may already be accounts in odd states: people suspended long ago and never revisited, deactivated users whose app accounts remain, and active users who have not signed in for a year. Cleaning these up lowers risk and cost.

A safe cleanup order

Short, wrong beliefs cause long, costly mistakes.

Not every account belongs to a regular employee.

A company’s directory holds more than staff. Each kind of account has its own risks, and the best action changes with the kind.

Why service accounts need special attention

A service account is an account used by a program, such as a nightly job that reads data. If you suspend it, the job stops. That may be exactly right in a break-in, or a painful surprise on an ordinary day. Always know which systems depend on an account before you touch it, and keep a record of its owner.

A short pause before the button can save a long recovery after it.

These questions fit on a card by your desk. Work through them in order, and the right action almost always becomes clear.

Keep this chapter handy. Every important word is explained here.

Account and status words

Action words

System words