Get started

Configure Okta Privileged Access to authenticate automated workloads so they can securely access privileged resources.

The process requires collaboration between two admin roles:

DevOps admin: Creates and tests the machine's identity configuration and is familiar with the source system.
Security admin: Governs the access, approves the identity configuration for live use, and defines authorization policies.

Phase	Role	Action
Phase 1: Connect	DevOps admin	Creates the workload connection in Draft status. In Draft mode, the CLI returns a successful validation message, but it doesn't issue a usable token. This allows you to verify your claim logic without granting access. See Configure workload connection. Tests the specific non-interactive command (`sft workload authenticate`) that the automation script uses. This verifies the CLI syntax and confirms that the workload's JWT passes validation against the draft connection. See CLI command for workload authentication. Note: If you run `sft workload authenticate` while in Draft state, the system requires approximately 5 minutes to refresh the workload connection details after switching to Active before issuing a tamper-proof Okta Privileged Access token.
Phase 2: Governance	Security admin	Reviews and promotes the connection from Draft to Active. See Manage a workload connection. Upon activation, the DevOps admin loses write access to the workload connection.
Phase 3: Logic	Security admin	Creates a workload role, defining the attribute-based conditions that determine who qualifies for the role. See Configure workload roles. Creates or updates the policy, selecting the new workload role as the principal. See Create or update a security policy.
Phase 4: Deploy	DevOps admin	Injects the `sft wl auth` into the workload's CI/CD pipeline. The automated workload runs the enhanced Okta Privileged Access client command, referencing the active workload connection name. Access events are logged to the Okta System Log.