Letting someone into an application is only half the story. The other half is deciding what they may do there.

For many years, access control in companies meant a simple yes or no per application. You either had the app or you did not. That was easy to manage, but it hid a big problem. Inside most real applications, there are many levels of power. A sales system may have viewers, editors, regional managers, and administrators. A finance system may have people who can enter an invoice and different people who can approve it. If the only question Okta answers is “does this person have the app,” then the real decisions about power are made somewhere else, often by hand, by whoever happens to be an administrator in that app.

The slow creep of too much access

People change jobs, take on projects, and cover for colleagues. Each time, they collect a little more access. Rarely does anyone take the old access away. After a few years, a long-serving employee may hold far more power than their present role needs. Security people call this privilege creep. It matters because a stolen account with many entitlements is a much bigger disaster than a stolen account with only a few.

The audit problem

Auditors regularly ask questions such as: who can approve payments over a certain amount, who can change customer data, and when was that access last reviewed? If the answers live in dozens of applications, each with a different screen, answering takes weeks. Entitlement management centralizes the question so that the answer takes minutes.

The productivity problem

Too little access also hurts. If new staff wait days for the right permissions, they cannot work. If requests are lost in email, people lose patience and ask colleagues to share their accounts, which is worse. A clear way to ask for access, with clear owners who approve it, makes the right access arrive quickly.

A small set of words appears again and again in this topic. Learn them once and the rest reads easily.

Identity

An identity is the digital record of a person or a system that needs access. It holds facts such as a name, department, manager, and status.

Authentication and authorization

Authentication proves who you are, like showing a passport. Authorization decides what you may do once you are known, like a border officer deciding whether your visa allows work. Entitlements belong to authorization.

Entitlement

An entitlement is a specific permission or level of access inside an application or resource. Examples are “can approve invoices,” “can edit customer records,” or “member of the support team with refund rights.” An entitlement is smaller than an application and more precise than a job title.

Entitlement value

Many entitlements come as a named set of choices. The entitlement might be “role in the sales tool,” and the values might be viewer, editor, and manager. A person can be given one or several values, depending on how the application works.

Entitlement bundle

A bundle is a named package of entitlements that go well together, often across several applications. A “New Sales Representative” bundle might include the sales tool as editor, the email tool as standard user, and the training portal as learner. Bundles make requests simpler, because people ask for a package instead of a long list of parts.

Role

A role is a collection of permissions that matches a job function. Roles are a longstanding way to organize access, and a bundle can be thought of as a modern, governed form of this idea.

Least privilege

The principle of least privilege says that every person should have the smallest set of permissions needed to do their job, and no more. It is the guiding rule of this entire subject.

Access request

An access request is a formal ask for an entitlement or bundle, with a reason, sent to an approver. It leaves a record of who asked, who approved, and when.

Access review or certification

A review is a periodic check where owners or managers look at who holds which access and confirm it is still needed. People who still need it are kept, and the rest are removed. The word certification is often used for the same idea.

Separation of duties

Separation of duties says that certain powers must never be held by the same person. The classic example is that the person who creates a payment must not be the one who approves it. This stops one person from committing and hiding a fraud.

Okta has many parts. It helps to see which part does what, so that entitlements have a clear home.

The sign-in layer

The first layer is sign-in: single sign-on, multi-factor authentication, and policies that decide how strongly each person must prove who they are. This layer answers “who are you, and are you really you?”

The lifecycle layer

The second layer is the lifecycle: creating accounts when people join, updating them when they move, and switching them off when they leave. It is driven by sources such as a human resources system, and it uses connections such as SCIM to keep applications in step. This layer answers “does this person have an account, and is it in the right state?”

The governance layer

The third layer is governance, the home of entitlement management. It answers the harder questions: what exactly can this person do in each application, who approved it, is it still appropriate, and does it break any rule? In Okta this area is commonly offered under the name Okta Identity Governance, with features such as entitlement management, access requests, access certifications, and workflows that automate the surrounding tasks. Which of these you have depends on your license and release.

How the layers cooperate

The three layers feed one another. The lifecycle layer creates the account. The governance layer decides which entitlements that account should hold. The lifecycle layer then pushes those entitlements into the application. The sign-in layer enforces how the person authenticates when they use it. If any layer is missing, the picture is incomplete.

flowchart TD
    HR["HR system
joiners, movers, leavers"] --> UD["Okta Universal Directory
identities and attributes"]
    UD --> GOV["Governance layer
entitlements, bundles, requests, reviews"]
    GOV --> LIFE["Lifecycle layer
provisioning to applications"]
    LIFE --> APP["Applications
accounts and permissions"]
    UD --> AUTH["Sign-in layer
SSO and MFA"]
    AUTH --> APP
    APP -->|"Reports current access"| GOV
    

Okta does not invent entitlements. They already exist inside your applications. Okta learns about them, organizes them, and governs them.

The application owns the truth

An application decides what its own permissions mean. A billing system defines what “approver” can do. Okta cannot change that meaning. What Okta can do is learn the list of permissions the application offers, know who holds each one, and help grant or remove them in a controlled way.

Learning the list

For supported applications, Okta can read the application’s available entitlements and their values through the integration used for provisioning. For some applications this happens automatically when the integration is connected. For others, an administrator describes the entitlements manually. Support differs by application and release, so check which of your applications can share entitlements and in what way.

Granting and removing

When a person should hold an entitlement, Okta tells the application through its provisioning connection. When they should lose it, Okta tells the application to remove it. The application stays the place where the permission actually takes effect, and Okta is the place where the decision is made and recorded.

Reading what is really granted

People can also be given permissions directly inside the application, bypassing Okta. Good governance needs to see these too. Okta can import the current state of access from supported applications, so that reviews are based on reality, not on what everyone believes should be true.

Naming and describing

Raw names inside applications are often cryptic, such as a code or an abbreviation. A governance system lets administrators add a plain-language name and description so that approvers and reviewers understand what they are approving. “Role 7B” means nothing to a manager. “Can approve payments up to the department limit” means a lot.

sequenceDiagram
    participant A as Application
    participant O as Okta governance
    participant P as Person or owner
    A->>O: Share list of entitlements and values
    O->>O: Add plain-language names and owners
    P->>O: Request or be assigned an entitlement
    O->>A: Grant through provisioning
    A-->>O: Confirm granted
    A->>O: Report current access on import
    

Asking for ten separate permissions is tiring and error-prone. Bundles turn many small choices into one sensible choice.

What a bundle holds

A bundle is a named group of entitlements, possibly across several applications. It has a name, a description, an owner, and often rules about who may request it. For example, a bundle called “Customer Support Agent” might hold a ticketing role, read access to the customer system, and membership in the support chat.

Why bundles help

• Simplicity: people choose a job-shaped package instead of a technical list.
• Consistency: everyone with the same job gets the same access, so there are fewer surprises.
• Speed: new joiners can receive a whole starter package at once.
• Review: reviewers examine a bundle once, instead of re-examining each part for each person.
• Change: if the package needs a new permission, you change the bundle once.

How big should a bundle be?

Too big, and it grants far more than anyone needs, defeating least privilege. Too small, and you are back to long lists. A good size matches a recognizable job task or role. Many teams have a small “baseline” bundle that everyone gets, a “role” bundle for each job family, and a few “extra” bundles for special duties.

Ownership

Every bundle needs a named owner who understands its purpose and is responsible for keeping it correct. Without an owner, bundles drift: permissions pile up and nobody dares remove them.

Time limits

Some bundles are meant to be temporary, such as access for a short project or an on-call week. Where supported, set an end date so the access ends by itself.

flowchart TD
    B["Bundle: Customer Support Agent"] --> E1["Ticketing tool
agent role"]
    B --> E2["Customer system
read-only"]
    B --> E3["Support chat
member"]
    B --> OW["Owner: head of support"]
    B --> RL["Rule: who may request it"]
    B --> ED["Optional end date"]
    

Okta offers several ways to express access. Knowing which to use when keeps your design tidy.

Groups

A group is a collection of people. Groups are flexible and widely used to assign applications and to drive policies. Groups answer “who belongs together.” They say little about what exactly each person can do inside an app, unless the app interprets group membership as a role.

Attributes

An attribute is a fact about a person, such as department, country, or manager. Attributes can drive rules automatically, and can be sent to applications.

Roles inside the application

Many applications have their own built-in roles. These are the actual permissions. Okta may pass a role name along, but the app interprets it.

Entitlements

Entitlements in the governance sense describe those inside-the-application permissions in a way Okta understands, with governance features attached: owners, requests, reviews, and rules.

Using them together

These tools complement each other. A typical design uses attributes from the human resources system to place people in groups. Groups assign applications and baseline bundles automatically. Entitlements and bundles describe finer permissions. Requests and reviews handle the exceptions. Each tool does the job it is best at.

flowchart LR
    ATTR["Attributes
department, location"] --> RULE["Rules"]
    RULE --> GRP["Groups"]
    GRP --> APPASN["Application assignment"]
    GRP --> BASE["Baseline bundle"]
    APPASN --> ENT["Entitlements in the app"]
    BASE --> ENT
    REQ["Access requests"] --> ENT
    REV["Reviews"] -.->|"keep or remove"| ENT
    

Every permission has a life: it is defined, granted, used, reviewed, and eventually removed. Governance means caring about every stage.

Define

First, someone decides that a permission exists and describes it in plain language. They name an owner, mark how sensitive it is, and note any rules, such as who may hold it and which other permissions it must never be combined with.

Assign or request

People receive the entitlement in one of two ways. Some access is predictable, so rules assign it automatically, for example to everyone in a department. Other access is exceptional, so a person asks for it and an approver decides.

Approve

The right people examine the request. They might be the person’s manager, the entitlement owner, a security team, or a chain of several. They approve, deny, or ask for more information. Their decision is recorded.

Grant

After approval, Okta tells the application to add the permission. It then waits for confirmation. If the application cannot do it, the failure must be visible, not silent.

Use

The person uses the access. Applications and Okta logs record sign-ins and actions. Unused access is a clue: if nobody has used a permission for months, it may be unneeded.

Review

At regular intervals, or after big events such as a job change, owners and managers re-confirm that the access is still appropriate.

Revoke

When access is no longer needed, it is removed. This may be triggered by an expiry date, a review decision, a job change, or a departure. Removal must reach the application, not just Okta’s records.

stateDiagram-v2
    [*] --> Defined
    Defined --> Requested : "Person asks"
    Defined --> Assigned : "Rule assigns"
    Requested --> Approved : "Approver agrees"
    Requested --> Denied : "Approver refuses"
    Approved --> Granted : "Application confirms"
    Assigned --> Granted : "Application confirms"
    Granted --> InReview : "Review begins"
    InReview --> Granted : "Keep"
    InReview --> Revoked : "Remove"
    Granted --> Revoked : "Expiry or leaver"
    Denied --> [*]
    Revoked --> [*]
    

Requests are the front door of governed access. A good request process is easy for people and hard to abuse.

Making a request

A person browses a catalog of what they may request, picks an entitlement or bundle, states a reason, and perhaps sets a duration. The catalog should show plain names and descriptions, and only items the person is allowed to ask for. A person who sees only relevant choices makes fewer mistakes.

Choosing approvers

Approvers should be the people who truly know whether the access is appropriate. Common choices are the requester’s manager, the owner of the entitlement, or both in sequence. For highly sensitive access, a security or compliance reviewer may be added. Avoid long chains for ordinary access, because each extra step slows people down and tempts them to find workarounds.

Making approval easy

Approvers are busy. Give them everything they need in one place: who is asking, what the access allows, why they want it, what they already hold, and whether it conflicts with any rule. Approvals should be possible from the tools approvers already use, such as chat or email notifications that link to the decision screen.

Handling delays and absence

Approvers go on holiday. Set up reminders and escalation, so a stuck request goes to a backup after a set time. A request with no response should not sit forever or be approved automatically without thought. Decide your rule on purpose.

Recording the decision

Every request should leave a record: who asked, who approved, the reason given, the time, and the result. This record is gold during an audit.

sequenceDiagram
    participant P as Person
    participant O as Okta request catalog
    participant M as Manager
    participant W as Entitlement owner
    participant A as Application
    P->>O: Choose entitlement, give reason and duration
    O->>M: Ask for approval
    M-->>O: Approve
    O->>W: Ask for second approval
    W-->>O: Approve
    O->>A: Grant access
    A-->>O: Confirmed
    O-->>P: Access ready
    

Most access is predictable. Rules can grant it automatically and consistently.

Birthright access

Birthright access is what a person should receive simply by being who they are: an employee, a member of a department, or a contractor of a certain type. Examples are email, chat, the staff directory, and tools for a particular team. Birthright access should arrive on the first day without anyone asking.

How rules decide

Rules look at facts about the person: department, job family, location, manager, employment type, and start date. When the facts match, the rule assigns a group, an application, or a bundle. Because the facts come from the human resources system, the access follows the person automatically as their job changes.

Movers

When someone changes department, two things should happen. New access for the new role is granted, and old access from the previous role is removed. The second is the part that gets forgotten. Rule-driven assignment helps because the old rule no longer matches, so its access can be withdrawn automatically. Pay special attention to access that was granted by request rather than by rule, as it will not disappear on its own. It should be re-confirmed during the move.

Leavers

When someone leaves, all access should end promptly. Automatic deprovisioning from the human resources trigger is the most reliable way, supported by a final sweep that checks nothing remains.

Keep rules readable

Rules based on clean, trusted attributes are easy to understand. Rules built on messy free-text fields are fragile. If rules start to look like puzzles, step back and improve the data instead.

flowchart TD
    HR["HR event: joiner, mover, or leaver"] --> ATT["Attributes updated in Okta"]
    ATT --> RULES{"Which rules now match?"}
    RULES -->|"New match"| ADD["Grant bundle or group"]
    RULES -->|"No longer matches"| REM["Withdraw rule-based access"]
    RULES -->|"Leaver"| ALL["Remove all access"]
    ADD --> CHK["Check requested access still fits"]
    REM --> CHK
    

Reviews are the safety net. They catch what rules and requests miss.

What a review campaign is

A campaign is a planned review round. It has a scope (which applications, entitlements, or people), reviewers (managers, owners, or both), a deadline, and rules for what happens to undecided items. Reviewers see a list and, for each item, choose to keep or remove.

Who should review

Managers know whether their people still need access for the work they do today. Entitlement owners know whether the permission is still appropriate and who should hold it. Many reviews use both: the manager confirms the person, the owner confirms the permission. Avoid asking people to review their own access, as the conflict of interest is plain.

Making reviews meaningful

A review with a thousand rows and a single click for “approve all” is a ritual, not a control. To help reviewers decide, show helpful context: when the access was granted, when it was last used, how it compares with peers, and any risk flags. Focus effort on high-risk items and consider lighter review for low-risk ones.

Acting on the results

The review is only useful if decisions are carried out. When a reviewer chooses remove, Okta should remove the access in the application, and record the evidence. Define what happens to items nobody reviews by the deadline. Options include escalating to a backup reviewer or, for risky access, treating silence as a removal.

Frequency

Match frequency to risk. Sensitive access may be reviewed quarterly, ordinary access annually, and event-driven reviews can follow big changes such as a reorganization or a job move.

flowchart TD
    S["Define scope and reviewers"] --> L["Launch campaign"]
    L --> R["Reviewers see items with context"]
    R --> D{"Decision"}
    D -->|"Keep"| K["Access stays, evidence saved"]
    D -->|"Remove"| X["Okta removes access in the app"]
    D -->|"No answer by deadline"| E["Escalate or apply default"]
    K --> C["Close campaign and report"]
    X --> C
    E --> C
    

Some powers are safe on their own but dangerous together. Separation of duties keeps them apart.

The idea

If one person can both create a payment and approve it, they could pay themselves without anyone noticing. If the two powers are held by different people, a fraud needs at least two to cooperate. This simple structure prevents a great deal of error and abuse.

Defining conflicts

Start by listing pairs of entitlements that must not be held together. Examples are creating and approving payments, requesting and approving access, and developing and deploying to production. Business owners and auditors usually help decide the list. Keep it focused on the highest-risk pairs.

Detecting and preventing

Where Okta supports it, rules can warn or block when a request would create a conflict. They can also detect conflicts that already exist, so owners can resolve them. Prevention at request time is better than discovery later, but you need both because access can also change inside applications.

Exceptions

Sometimes a small team genuinely needs a person to hold both powers. Handle this as a recorded exception with a named approver, a reason, extra monitoring, and a short expiry. Do not leave exceptions open forever.

flowchart TD
    REQ["New request"] --> CHK{"Would it create a conflict with existing access?"}
    CHK -->|"No"| GO["Continue normal approval"]
    CHK -->|"Yes"| BL{"Exception allowed?"}
    BL -->|"No"| STOP["Block request and explain why"]
    BL -->|"Yes"| EXC["Exception approval, reason, short expiry"]
    EXC --> GO
    

Governance involves many small follow-up tasks. Automation keeps them from being forgotten.

Notifications and reminders

People need to be told when a request awaits their decision, when access is about to expire, and when a review is due. Automatic messages with clear links save time and prevent delays.

Expiry and renewal

Time-limited access should end on its date without anyone remembering. Before it ends, the holder and their manager can be asked whether to renew. Renewal should need a short reason, so access does not live forever by habit.

Event-driven checks

Some events call for an immediate look at access: a job change, a long leave, a new manager, or a security alert. Workflows can start a targeted review or remove risky access automatically when such events occur.

Connecting to other systems

Governance often touches systems beyond Okta: ticketing tools for tracking, chat for approvals, and messaging for reminders. Okta’s automation features, where available, can connect these steps so that one event starts the whole chain.

Evidence collection

Keep records of requests, approvals, reviews, and removals in a form auditors can read. Automated evidence is more reliable than screenshots taken in a rush before an audit.

flowchart LR
    EV["Event: job change, expiry, alert"] --> WF["Automated flow"]
    WF --> CK["Check access and conflicts"]
    CK --> AC{"Needs a human?"}
    AC -->|"Yes"| ASK["Notify reviewer with context"]
    AC -->|"No"| DO["Grant or remove automatically"]
    ASK --> DO
    DO --> LOG["Write audit record"]
    

An entitlement system is a handful of cooperating parts. Seeing each part makes the whole easier to reason about.

The source of truth for people

Usually this is a human resources system. It knows who works for the company, their job, department, manager, and dates. Okta’s directory receives this information and keeps it as the shared view of each identity.

The catalog

The catalog is the list of things people can hold or ask for: applications, entitlements, and bundles, each with plain names, descriptions, owners, and sensitivity. It is the menu of the governance system.

The policy and rule engine

This part holds the rules: which attributes lead to which automatic assignments, who may request what, how many approval steps a request needs, and which combinations are forbidden. It is where your company’s decisions are written down in a form the system can follow.

The workflow engine

This part carries out multi-step processes: send a request to the manager, then to the owner, remind after two days, escalate after five, then grant. It also runs review campaigns and event-driven checks.

The connectors

Connectors link Okta to applications. They read the available entitlements, grant and remove them, and import current access. A connector is the hands of the system.

The evidence store

Every decision and change is recorded: who asked, who approved, when it was granted, when it was reviewed, and when it was removed. This is the memory auditors rely on.

The people-facing screens

Employees use a request catalog. Approvers use an inbox. Reviewers use a campaign screen. Administrators use configuration and reports. Good screens decide whether people use the system or work around it.

flowchart TD
    HR["HR system"] --> DIR["Directory
identities and attributes"]
    DIR --> POL["Policy and rule engine"]
    CAT["Catalog
apps, entitlements, bundles"] --> POL
    POL --> WF["Workflow engine
requests, approvals, reviews"]
    WF --> CON["Connectors"]
    CON --> APPS["Applications"]
    APPS -->|"Import current access"| CON
    WF --> EVI["Evidence store and reports"]
    UI["Request catalog, approver inbox, reviewer screen"] --> WF
    

A catalog that people can understand is the heart of the system. A confusing one defeats everything built on it.

Plain names

Use names that describe what the person can do, in the language of the business. “Approve supplier invoices” is better than “AP_ROLE_3”. Add a one-sentence description and an example of who normally needs it.

Owners

Every entitlement has an owner who understands it and decides who should hold it. Owners should be people close to the business purpose, not only technical administrators. Name a backup owner as well.

Sensitivity levels

Mark each entitlement with a level, such as low, medium, high, or critical. The level drives how many approvals are needed, how often it is reviewed, and whether it can be time-limited. Keep the scale small and well defined, so people apply it consistently.

Tags and categories

Group entitlements by business area, such as finance, sales, or engineering. Tags help people find what they need and help reviewers filter large lists. Keep tag names consistent.

Rules attached to an item

Some items should be requestable only by certain people, such as employees in a given department. Some should not be combined with others. Record these rules next to the item so that the logic is easy to find.

Keeping it tidy

Retire entitlements that are no longer used. Merge duplicates. Review descriptions every year. A catalog that is only ever added to becomes a junk drawer.

flowchart LR
    RAW["Raw app permission
cryptic code"] --> NAME["Plain name and description"]
    NAME --> OWN["Owner and backup"]
    OWN --> SENS["Sensitivity level"]
    SENS --> RULE["Request and conflict rules"]
    RULE --> CAT["Published in the catalog"]
    

Governance is only as good as its link to the real application. A decision that never reaches the app is only a note.

Tiers of integration

Applications differ in how well they can be connected. At the best level, an application supports a standard provisioning connection and can share, grant, and remove entitlements and report current access. At a middle level, it can create and remove accounts but has limited permission detail. At the lowest level, it has no connection at all and changes must be done by hand or through a ticket.

Supported connectors

For popular applications, Okta may provide ready-made integrations that already understand the application’s entitlements. Check the catalog of integrations for your applications and your release to see what is supported and how deeply.

Custom connections

For your own applications, you can often build a standard provisioning service so Okta can talk to them. The more your application exposes about its permissions, the more Okta can govern.

Manual and ticket-based fulfilment

When no connection exists, Okta can still hold the decision, while a human or a ticketing system carries it out in the application. Treat these as second-best: they are slower and have more room for error. Track them closely and plan to improve them.

Importing current access

Before reviewing, import what people actually hold. Compare it with what Okta thinks they should hold. Differences are the most interesting findings in any governance project.

Failure handling

Connections fail. Plan for retries, alerts when grants fail, and a clear owner for fixing stuck items. A grant that fails silently leaves the person without access and the audit trail pretending everything is fine.

flowchart TD
    APP["Application"] --> Q1{"Supports standard provisioning with entitlements?"}
    Q1 -->|"Yes"| T1["Tier 1: full governance
share, grant, remove, import"]
    Q1 -->|"Accounts only"| T2["Tier 2: partial
accounts managed, permissions by hand"]
    Q1 -->|"No connection"| T3["Tier 3: manual or ticket
decision in Okta, action by a person"]
    T1 --> MON["Monitor failures and drift"]
    T2 --> MON
    T3 --> MON
    

Good bundles are discovered, not guessed. They come from understanding how people really work.

Start with real access

Look at what people in the same job actually hold. Often, a clear core emerges that nearly everyone holds, and a set of extras that only a few have. The core becomes the role bundle. The extras become separate, requestable items.

Talk to the business

Data tells you what people hold, not what they should hold. Managers and owners can tell you which access is essential and which is historical baggage. Combine data and conversation.

Avoid role explosion

If you create a new bundle for every small difference, you end up with more bundles than people. This is called role explosion, and it makes the system as hard to manage as the problem it replaced. Prefer a small set of well-chosen bundles, plus the ability to request extras.

Layer the bundles

A useful structure has three layers. A baseline for everyone. A role layer for each job family. An optional layer for special duties and temporary needs. Layers keep each bundle small and understandable.

Test with real people

Before publishing a bundle, try it on a few real people from the role. Ask whether it gives them what they need on the first day, and whether anything is missing or surprising.

Maintain

Jobs change. Review bundles regularly with their owners. Remove permissions that nobody uses. Add new ones when tools change. Version your changes and record the reasons.

flowchart TD
    BASE["Baseline bundle
everyone"] --> ROLE["Role bundle
job family"]
    ROLE --> OPT["Optional bundles
special duties"]
    OPT --> TMP["Temporary access
time-limited"]
    DATA["What people hold today"] --> DISC["Discover common core"]
    BIZ["Business owner input"] --> DISC
    DISC --> ROLE
    

Rules are only as good as the facts they read. Poor data produces wrong access quickly and at scale.

Which facts matter

Most governance rules rely on a handful of facts: employment status, department, job family, location, manager, and start and end dates. Make sure these are present, correct, and in a consistent format.

One source for each fact

Decide which system is the authority for each fact, and make Okta read it from there. If two systems both claim to own the manager, they will disagree, and rules will behave unpredictably.

Who can change the facts

If people can edit the attributes that drive their own access, they can promote themselves. Make attributes used for access decisions read-only for users and changeable only through trusted sources and reviewed processes.

Standard values

Free-text department names such as “Fin”, “Finance”, and “finance dept” create three groups where you want one. Use controlled lists with agreed values, and clean up historical data before relying on it.

Timing

Changes should flow quickly. If a person’s department changes on the first of the month but the update reaches Okta weeks later, they will hold the wrong access in the meantime. Understand the delays in your pipeline.

Monitoring quality

Report on missing managers, odd department values, and mismatches between systems. Fixing data at the source improves every rule that depends on it.

flowchart LR
    SRC["Authoritative source"] --> CLEAN["Validate and standardize"]
    CLEAN --> DIR["Okta directory"]
    DIR --> RULE["Rules read trusted attributes"]
    RULE --> ACC["Access assigned"]
    MON["Data quality reports"] -.-> SRC
    MON -.-> CLEAN
    

Governance projects fail when they try to do everything at once. A phased path builds confidence and value.

Phase 1: Understand

Choose the applications that matter most, usually those with sensitive data or many users. Document who currently holds what. Identify owners. Agree on the goals: fewer risky permissions, faster onboarding, passing audits, or all three.

Phase 2: Build the foundation

Clean the data, define the catalog for the first applications, connect them, and write plain names and descriptions. Decide sensitivity levels and review frequencies.

Phase 3: Automate the predictable

Create baseline and role bundles, and rules that assign them from trusted attributes. Confirm joiners, movers, and leavers behave correctly.

Phase 4: Add requests

Open the request catalog for the extras. Design approvals by sensitivity. Train approvers and measure turnaround times.

Phase 5: Add reviews

Run a first review campaign on the highest-risk access. Learn from reviewers’ feedback and refine the context shown to them.

Phase 6: Tighten and extend

Add separation-of-duties rules, time-limited access, and more applications. Monitor, report, and improve.

flowchart LR
    P1["Understand"] --> P2["Foundation"]
    P2 --> P3["Automate"]
    P3 --> P4["Requests"]
    P4 --> P5["Reviews"]
    P5 --> P6["Tighten and extend"]
    P6 -.->|"Learn and repeat"| P1
    

Examples make ideas stick. Each one below follows a person through the system, step by step.

Example 1: A new sales representative

Priya joins the company as a sales representative in the Mumbai office. On her start date, the human resources system records her department, job family, location, and manager. Okta reads these facts. A rule notes that she is an employee, so she receives the baseline bundle: email, chat, and the staff directory. Another rule notes that her job family is sales, so she also receives the sales role bundle: the customer system as editor, the quote tool as standard user, and the training portal as learner. By the time she sits down, she can work.

After two weeks, she needs to approve discounts for her regional accounts. That is a more powerful permission, so it is not part of the bundle. She finds “Approve discounts up to the regional limit” in the request catalog, writes a reason, and submits. Her manager approves first, then the owner of the discount permission. Okta grants it and the customer system confirms. The record shows who asked, who approved, and when.

Example 2: A move from sales to finance

A year later, Priya moves to the finance team. The human resources system updates her department. The sales role rule no longer matches, so the sales bundle is withdrawn. A finance role rule matches, so the finance bundle is added. But the discount-approval permission was requested, not assigned by rule. The mover process flags it for re-confirmation. Her new manager sees “Approve discounts” and decides it is not needed. It is removed.

Without that flag, Priya would have held a sales approval power in a finance job. That is how privilege creep begins.

Example 3: A conflict caught early

In finance, Priya asks for “Approve supplier invoices”. The system checks her current access and notices she already holds “Create supplier invoices”. These two are marked as conflicting. The request is blocked with a clear message. Her manager chooses to assign the approval power to a different colleague instead, and the problem never appears in an audit.

Example 4: A quarterly review

Each quarter, the owner of the payments system reviews who holds the high-risk “Release payments” permission. The screen lists twelve people, with the date each was granted and the date each last used it. Two have never used it in six months. The owner removes those two. Okta tells the payments system, then imports current access to confirm the removal worked.

Example 5: A leaver

Priya later resigns. On her last day, the human resources system marks her as terminated. Okta removes her group memberships and bundles, switches off her accounts, and tells each connected application to remove her entitlements. Applications without a connection receive a ticket. A final sweep checks that nothing remains.

sequenceDiagram
    participant HR as HR system
    participant O as Okta
    participant M as Manager
    participant A as Applications
    HR->>O: Priya joins sales
    O->>A: Grant baseline and sales bundles
    O->>M: Request for discount approval
    M-->>O: Approved
    O->>A: Grant discount approval
    HR->>O: Priya moves to finance
    O->>A: Remove sales bundle, add finance bundle
    O->>M: Re-confirm discount approval
    M-->>O: Not needed
    O->>A: Remove discount approval
    HR->>O: Priya leaves
    O->>A: Remove all access
    

A system that controls who can do what is itself a prime target. Protect it with care.

Protect the governance system itself

Anyone who can edit rules, bundles, or approvals can effectively grant access. Limit those rights to a small group of trained administrators, require strong sign-in for them, and review who holds those rights as often as any other high-risk access.

Guard the approvers

Attackers may try to trick approvers into approving bad requests, or take over an approver’s account. Show approvers clear information, require strong authentication for sensitive approvals, and watch for unusual approval patterns such as many approvals in seconds.

Least privilege everywhere

The connections between Okta and applications hold their own powers. Give each connection only the rights it needs. A connection that can do everything is a perfect target.

Protect the attributes

Rules rely on attributes. If a person can change their own department, they may change what the rules give them. Make sure attributes used in access decisions are controlled by trusted sources.

Guard against self-approval and collusion

Do not allow people to approve their own requests or review their own access. For the most sensitive access, require approvers from different parts of the business so that one person or one friendly pair cannot push something through.

Time limits and break-glass

For powerful access, prefer time-limited grants. For emergencies, provide a pre-approved, carefully monitored path that grants short access and triggers an after-the-fact review. This is better than people sharing admin accounts.

Protect the evidence

Evidence records must not be changeable by the people they describe. Store them so they cannot be silently edited, and keep them for the period your rules require.

flowchart TD
    A["Request or change"] --> B["Strong authentication of the actor"]
    B --> C["Authorization: may this person do this?"]
    C --> D["Policy and conflict checks"]
    D --> E["Approval by independent people"]
    E --> F["Least-privilege grant to the application"]
    F --> G["Immutable audit record"]
    G --> H["Monitoring and alerts"]
    

You cannot manage what you cannot see. A few good measurements reveal whether governance is working.

What to log

Record every request, approval, denial, grant, removal, rule change, and review decision, with who did it, when, and why. Also record failures: grants that did not reach the application, and connections that stopped responding.

Metrics that matter

• Time to access: how long a new joiner waits for working access, and how long a request takes from submission to grant.
• Approval turnaround: how long approvers take, and how many requests need reminders or escalation.
• Review completion: the share of items decided on time, and the share removed.
• Rubber-stamp rate: how many items are approved in seconds, with no change.
• Drift: differences between what Okta thinks people hold and what applications report.
• Orphaned accounts: application accounts with no matching person.
• Conflicts: number of people holding conflicting powers, and number of open exceptions.
• Stale access: high-risk permissions unused for a long time.
• Failed grants: count and age of grants that did not complete.

Alerts

Alert on events that need quick action: a failed removal for a leaver, a new conflict, a burst of approvals from one person, a change to a high-risk bundle, or a campaign nearing its deadline with little progress.

Reports for different readers

Executives want a few trend lines: risk going down, speed going up. Owners want lists of their own entitlements and holders. Auditors want evidence for samples. Provide each with a view that suits them.

flowchart LR
    EV["Events and logs"] --> MET["Metrics"]
    MET --> DASH["Dashboards by audience"]
    MET --> ALR["Alerts"]
    ALR --> OWN["Owner investigates"]
    DASH --> EXEC["Executives: trends"]
    DASH --> OWNR["Owners: their lists"]
    DASH --> AUD["Auditors: evidence"]
    

Many companies adopt entitlement management because auditors ask hard questions. Good design makes answers easy.

What auditors ask

Typical questions include: who has access to sensitive systems, who approved it, when was it last reviewed, how quickly is access removed for leavers, and how do you prevent one person from holding conflicting powers? The best defence is a system that can answer each question with a report.

Evidence by design

Design processes so evidence is produced as a by-product, not collected in a panic. Requests record reasons and approvals. Reviews record decisions and who made them. Removals record time and confirmation. When the audit comes, you export, not reconstruct.

Samples and populations

Auditors often pick a sample of people or changes and ask for proof of each. Make sure you can find a person’s full access history quickly and show each grant, approval, and review.

Privacy

Access data is personal data. Keep what you need, protect it, and follow your organization’s retention and privacy rules. Limit who can see the reports.

Different frameworks, similar needs

Financial reporting rules, security standards, and privacy laws differ in detail, but they ask for the same few things: least privilege, approval, regular review, timely removal, and evidence. Map your controls to each framework once, then reuse the evidence.

Technology is the easy half. The harder half is deciding who is responsible for what.

Who does what

• Platform team: runs Okta, builds connections, maintains rules and workflows.
• Entitlement owners: define and describe permissions, set sensitivity, approve requests, review holders.
• Managers: approve requests for their people and confirm access during reviews.
• Security and risk: define policies, conflict lists, and review frequencies; monitor results.
• Internal audit: test the controls independently.
• Employees: request what they need and report what they no longer use.

Keeping ownership alive

People change jobs. When an owner leaves, their entitlements become orphans, with nobody to approve or review. Include ownership in the leaver and mover process, and report on items with missing or inactive owners.

Scaling to many applications

Start with a handful of applications and grow in waves. Reuse patterns: the same baseline bundle, the same approval templates, the same review calendar. Each new application then takes days, not months.

Scaling to many people

Large organizations need rules that work on facts, so no one maintains lists by hand. Keep bundles few. Use automation for the predictable and humans for the exceptions. Watch for approver fatigue as volume grows.

Training and communication

Explain to employees why access changes, how to ask, and what to expect. Explain to approvers and reviewers what a good decision looks like. A system that people understand is one they use correctly.

Continuous improvement

Treat governance as an ongoing service. Review metrics every quarter, collect feedback, retire unused items, and adjust rules. A static design slowly falls out of step with the business.

flowchart TD
    OWN["Entitlement owners
define, approve, review"] --> PLAT["Platform team
builds and runs"]
    MGR["Managers
approve and confirm"] --> PLAT
    SEC["Security and risk
set policy"] --> PLAT
    PLAT --> EMP["Employees
request and use"]
    AUD["Internal audit
tests controls"] -.-> PLAT
    AUD -.-> SEC
    

Entitlement management delivers real benefits, and real costs. A fair picture helps you decide how far to go.

Key trade-offs

flowchart TD
    N["An access need"] --> R{"Risk level"}
    R -->|"Low"| A1["Automatic bundle by rule"]
    R -->|"Medium"| A2["Request with manager approval"]
    R -->|"High"| A3["Request, owner and security approval, time limit"]
    R -->|"Critical"| A4["Break-glass path with after-the-fact review"]
    

A pattern is a proven answer to a problem that keeps coming back. These patterns keep access small, clear, and reviewable.

Pattern: Baseline, role, extra

Use three layers. Everyone gets a small baseline. Each job family gets a role bundle. Special duties are separate, requestable extras. Each layer is easy to explain and review.

Pattern: Rules for the predictable, requests for the rest

If most people in a role need something, grant it by rule. If only a few do, make it a request with a reason. This keeps the request queue short and meaningful.

Pattern: Owner for every item

Every entitlement, bundle, and rule has a named owner and a backup. No item exists without someone accountable.

Pattern: Risk-tiered approval

Match the number and type of approvers to the sensitivity of the access. Low risk is quick. High risk gets more eyes and a time limit.

Pattern: Expire by default for powerful access

For high-risk entitlements, set an end date at grant time. Renewal needs a fresh reason. Access that ends by itself cannot be forgotten.

Pattern: Check conflicts at the door

Test for conflicting powers when a request is made, and again during reviews. Prevent where you can and detect where you cannot.

Pattern: Review with context

Show reviewers when access was granted, when it was last used, and how it compares with peers. Informed reviewers decide better and faster.

Pattern: Verify by importing

After granting or removing access, import the current state from the application and compare. Trust, but verify.

Pattern: Mover re-confirmation

On a job change, remove rule-based access automatically and ask the new manager to re-confirm each requested permission.

flowchart TD
    JOIN["Person joins or moves"] --> BASE["Baseline bundle"]
    BASE --> ROLE["Role bundle by rule"]
    ROLE --> NEED{"Needs something extra?"}
    NEED -->|"No"| DONE["Done"]
    NEED -->|"Yes"| REQ["Request with reason"]
    REQ --> CONF{"Conflict?"}
    CONF -->|"Yes"| BLK["Block or exception"]
    CONF -->|"No"| APP["Tiered approval"]
    APP --> EXP["Grant with expiry if high risk"]
    EXP --> VER["Verify by import"]
    

An anti-pattern is a habit that seems sensible but causes trouble later. Each card below shows one, why it hurts, and a better way.

This chapter gathers the habits that separate calm programs from chaotic ones.

Best practices

Common mistakes

These short stories use made-up companies to show how the ideas appear in daily work. They are teaching examples, not descriptions of any real organization.

What the scenarios share

Each story was solved by clear names, clear owners, rules for the predictable, requests for the rare, honest reviews, and verification against reality. None needed anything exotic. They needed discipline and patience.

Short answers to common questions. Where details depend on your license or release, confirm them in your own console and the official documentation.

Here is the whole story in a few lines you can carry with you.

Entitlement management answers a simple question: what exactly can each person do, and why? Signing in to an application is only the front door. Inside, many levels of power exist, and a company that cannot see them cannot control them. In Okta, governance features describe those permissions in plain language, package them into bundles, assign the predictable ones by rule, let people request the rest with clear approvals, review what is held, prevent dangerous combinations, and remove access when it is no longer needed.

The craft lies in a few steady habits: keep bundles small, give every item an owner, match the care to the risk, expire powerful access, review with context, verify against the application, and keep the data clean. With these, access stays small, onboarding stays fast, and audits become a matter of exporting evidence instead of reconstructing history.