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. 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.