Security policy

A security policy controls which principals are granted privileged access to one or more resources. As a security admin, you create a policy, assign principals to the policy, and add one or more rules.

When creating a rule, you can establish specific conditions that users must meet to access a resource that's safeguarded by Okta Privileged Access. These rules can be customized for different resources by stacking or adding them until they cover all the privileged access needed for the set of principals. By doing this, you can set different controls over different resources to ensure that only authorized users can access them.

You can assign security administration to groups assigned as delegated security administrators. The delegated security admins can create policies that apply to resource groups for which they're the security owners. Security policies written by delegated security administrators will only apply to the resource group they selected when crafting the policy. See Add a delegated security admin.

Security policy configuration options

When creating a security policy the following access control features can be configured:

Features Description
Principal Users and groups that are associated with the policy and are granted access to the matched resources. See Components for more information.

A rule is used to define the scope of resources and how privileged access is granted to the resources. Each security policy contains a rule that defines the resources and privileges available to each principal.

Security admins and delegated security admins can create the following rules:

  • Server rule
  • Secret rule. See Secrets.
Session type This is how users access resources. Session type can be SSH or RDP.

Privileged access to resources are based on the policy created by the security admin or delegated security admin. You can configure the scope of access to resources using the following methods.

  • Resources using labels

    Select which labels to use and include the servers that match the label when creating a rule. After defining the scope of the servers using labels, you can configure how principals access resources. Principals can access resources by signing in to servers with either an on-demand individual account, a vaulted local account, or both.

  • Resources by name

    Apply the policy to a specific resource; for example, apiserver-prod / pamadmin.

Root SSH login is disabled by default on most Linux installations.


You can apply labels to individual servers. These labels allow Okta Privileged Access teams to categorize and sort server access. There are two types of labels:

  • System-generated labels: When you add a server to Okta Privileged Access, several system-generated labels are automatically created based on characteristics such as hostname, server type, operating system, AWS, Azure, or Google Cloud Platform account ID.

  • Custom labels: You can configure labels directly in the server agent configuration file (sftd.yaml), which then appears in the Okta Privileged Access console for selection. To add custom labels to the server agent configuration file, see Custom Labels.

    Custom labels may impact server accessibility. Okta recommends using custom labels with caution.

Labels are stored in a key:value pair format to allow more flexibility for teams. For example, a server might have two labels, env:prod and env:test. Labels can originate from within the system or through the sftd configuration file. Okta Privileged Access automatically adds a prefix to identify the source of the label. If the env:prodlabel originated from Okta Privileged Access, the system prefix looks like the following: system.env:prod. Likewise, if the env:test label originated from the sftd configuration file, the sftd prefix look like the following: sftd.env:test. This avoids conflicts if the same label is added from multiple sources, which can happen if a label is specified by both the system and the server agent configuration file.

Session recording See Session recording.
Approval request See Okta Privileged Access with Access Requests
Multifactor authentication See Multifactor authentication.


  • Ensure that you're signed in to Okta Privileged Access.
  • You must have the Okta Privileged Access security admin role or a delegated security admin role.

Create or update a security policy

To create a policy, you need to add a policy name, assign principals, and create rules that apply to the principals. After a policy is created, it must be published. A policy doesn't have any effect until it's published.

  1. Go to Security Administration Policies..
  2. Click Create Policy.
  3. Enter a policy name and description.
  4. Configure the resource group information.

    Setting Action
    All resource groups

    Select this option to apply the following to all resource groups.

    Delegated security admins can't select this option.

    Specify a resource group

    Select this option to apply the policy to a specific resource group.

  5. Click Select PrincipalsAdd or modify.
  6. Select one or more groups that you want to add or modify, and then click Save.
  7. Add rule to define the scope of resources and how to grant privileged access to these resources. You can configure the following rules: Server rule and Secret rule.
    1. To add a server rule, select Add rule Server Rule.
      Rule nameEnter a rule name
      Choose a session typeUse the dropdown menu and choose a session type.
      Select the resources that you want to protect with this rule

      You can select resources by label or by name. Based on your selection, you need to perform other configuration.

      Select resources by label

      1. Toggle the button.
      2. In the Add resources field, search for and select a resource label. You can select multiple resource labels. See Security policy configuration options to learn more about labels.
      3. Select either one or both options on How you want principals to access the resources.

        • Access resources by individual account

        • Access resources by vaulted account

          Adding a local account, for example, #pamadmin, means that the #pamadmin account will be available on every server selected based on the labels.

      Select resources by name

      1. Toggle the button to enable it.
      2. Select one or more accounts individually.
      Optional. Enable session recording

      Okta resource admins must enroll and install a gateway before enabling session recording.

      1. Select Enable traffic forwarding through gateways.
      2. Select Record session through gateways.
      Optional. Configure approval requestsYou must create a Request Type in Access Requests first for the access request workflow to be visible in the security policy. See Okta Privileged Access with Access Requests.
      1. Select a workflow from the dropdown menu.
      2. Choose how long you want the approval to last.
      3. Optional. Select the setting to rotate the password after the approval duration ends.

      For Okta to take control of managing local account passwords on Windows servers, users must disable any password age restrictions that might prevent Okta from changing or rotating the password.

      Optional. Enable MFA

      Enable MFA to add a granular level of authentication and control within a policy.

      1. Toggle Enable MFA.

      2. Select one of the following options:

        • Any two-factor types

        • Phishing resistant

      3. Select one of the following re-authentication frequencies:

        • Every SSH or RDP connection attempt

          You can choose to enforce MFA for each attempt to access the resource.

        • After the specified duration

          By default, the specified duration is set to 30 minutes. You can specify a time duration ranging from 5 minutes to 12 hours.

      After the policy is implemented, when a user tries to connect with a resource, they'll need to complete the necessary MFA steps.

    2. To add a secret rule, select Add rule Secret Rule.

      Rule nameEnter a rule name.

      Select the secret folder or secret you want to protect with this rule

      1. Click Select secret folder or secret.

      2. Select a secret folder or a secret

      3. Click Save.

      Select Permissions

      Select the permissions. You must select at least one permission. See Secret permissions for details.

      Approval requests

      You must create a Request Type in Access Requests first for the access request workflow to be visible in the security policy. See Okta Privileged Access with Access Requests.

      1. Select the approval Request Type.

      2. Choose how long you want the approval to last.

  8. Click Save policy.You can now publish this policy.

Publish a policy

After a policy is created it must be published.

When a published policy is changed, the changes are applied immediately without the need to publish the policy again.

  1. Go to Security Administration Policies.
  2. On the policy you want to publish, click Actions.
  3. Click Publish to grant access to the policy.

Clone a policy

Security admins can clone an existing policy instead of creating an entirely new policy from scratch.

  1. Go to Security Administration Policies.
  2. On the policy you want to clone, click Actions.
  3. Select Clone.
  4. Click Save Policy.

Related topics

Okta Privileged Access with Access Requests

Multifactor authentication

Okta Privileged Access

Secret permissions