Capability

Privileged access

What it does: Admin rights granted just-in-time and recorded for auditability.

WIC

In short

Privileged access gives admins elevated rights only when they need them and for a limited time, and records what they did through Okta Privileged Access. Note: Session recording applies to privileged access that OPA brokers to servers and secrets, not to every action in the Okta Admin Console.1

4
attack types it helps against

What it is, and the attacks it stops

Admin accounts can change settings, read data and create other accounts. An attacker who takes one over gets all of that.

Privileged access controls how those rights are granted. Instead of leaving them on permanently, the admin requests them, receives them for a defined time and leaves a record of the session.12

That reduces the risk and impact of attacks such as:

1

Takeover of an admin account

An attacker phishes or guesses an admin's credentials. If the admin holds elevated rights only for short periods, the attacker finds fewer standing rights to use.

2

Standing access that nobody uses

An admin keeps rights from an old project. The rights remain open to an attacker long after the work ended.

3

Shared admin passwords and keys

A password or key is passed around a team. Nobody can tell who used it, and it is easy to copy.

4

Insider misuse

A person with broad rights looks at or changes data they do not need. Without a record, nobody can reconstruct what happened.

Before and after rollout

Without
With
WithoutAdmins keep elevated rights all the time.
WithAdmins request elevated rights when they need them, and the access is time-limited.1
WithoutSecrets and credentials for servers sit in spreadsheets, chats and personal vaults.
WithOkta Privileged Access describes managing secrets and server access in one place.1
WithoutNobody can say who used an admin account or what they did.
WithOkta Privileged Access records sessions for access it grants to servers and secrets, so reviews can show who did what.1
WithoutRights granted once are rarely reviewed.
WithAccess requests and reviews can be handled with Okta Identity Governance.2

How Okta does it

Okta Privileged Access works together with the rest of Workforce Identity. You can add it step by step.

1

The admin asks for access

The admin requests access to a server, a secret or an admin role instead of holding it permanently.12

2

Policy and an approver decide

Rules defined in Okta, and an approver where you require one, decide whether the request is granted.12

3

Access is granted for a limited time

The admin gets access for a defined period, and it ends afterwards.1

4

The session is recorded

Okta Privileged Access records sessions for the server and secret access it brokers, which gives you an audit trail for reviews and investigations.1

WIC
Who it protectsAdmins, engineers, contractors with elevated rights
Okta Privileged AccessOkta's product for managing access to servers and secrets, including time-limited access and session recording for that access.1
Access requestsOkta Identity Governance supports requesting and approving access, so rights are not granted by a chat message.2
Access certificationsOkta Identity Governance also supports periodic reviews of who holds which access.2
Admin roles in OktaAdmin access to Okta itself is controlled through administrator roles, which you can assign narrowly.3

How Zelto implements it

The technology behind Okta is the ready and proven half - Zelto maps who holds admin rights today and what they use them for. We plan rollouts in groups to minimize risk/impact. We start with the accounts and systems where a takeover would cost the most.

Typical rollout

  1. Map who holds admin rights and where

    We list admin roles, privileged accounts, shared credentials and the servers and apps they reach.

  2. Decide which rights become time-limited

    We separate rights that admins use daily from rights they use rarely, and we make the rare ones time-limited first.

  3. Pilot with the IT and security admins

    We start with the people who hold the most rights. Before any policy becomes required, we agree on an owner on your side. We also agree on approvers and on a way to get emergency access.

  4. Move one system at a time

    We move servers, secrets and admin roles into Okta Privileged Access and Okta policies step by step. We remove old shared credentials as each system is covered.

  5. Review and tighten

    We review the session records and the access reviews on a schedule, and we remove rights that nobody uses.

Pitfalls we plan for

An admin needs access urgently outside business hours.

−Keep a shared admin password in a chat so that anyone can get in quickly.

+Agree on an emergency path with an approver and a record, and test it before it is needed.

Approvals are required for every request.

−Approvers get dozens of requests a day and approve them without reading.

+Require approval only for high-risk access. Lower-risk access is granted by policy and still recorded.

Old shared credentials still exist after the rollout.

−Add the new tool and leave the old passwords valid, so the old path stays open to attackers.

+Rotate or remove each shared credential as soon as the system behind it is covered.

Contractors and vendors need admin access for a project.

−Give them a permanent account with the same rights as staff.

+Give each person their own account, grant rights for the length of the project and review them when it ends.

Want admin rights that are granted when needed and recorded, without slowing your admins down?

We review who holds admin rights in your environment today. Then we tell you which ones to make time-limited first.

Book a call30 minutes, no slides. We look at how admin access works for you today.

Related blog posts

Notes from rollouts

Sources

Official Okta and Auth0 documentation and primary legal sources.

  1. 1Okta Privileged Accessokta.com product page
  2. 2Okta Identity Governanceokta.com product page
  3. 3Okta Identity Engine documentationOkta Help Center