Skip to content

How to Rotate Credentials

Credential rotation is the process, either automated or on-demand, by which 12Port manages passwords or keys for privileged accounts. During this process, these credentials are reset based on custom-defined policies that enforce password complexity and randomness.

Managing highly sensitive credentials through 12Port significantly reduces the risk of exposed or leaked secrets, which could otherwise lead to major security incidents.

Credential Rotation Components

Credential rotation in 12Port relies on a set of integrated components that define and govern automation, security, and policy inheritance.

Asset Types At the core of every asset is its Asset Type, which defines:

  • The supported remote access protocol (e.g., RDP, SSH)
  • Vault fields for secret storage
  • Associated security controls
  • Tasks to support automated credential rotation

Many Asset Types are preconfigured with relevant Tasks. For instance, a Windows Host Asset Type includes predefined tasks for rotating Windows-based local account credentials.

Scripts Scripts are the core logic behind every credential rotation task. These are not hidden or black-box processes; they are fully visible and customizable by administrators. Depending on the asset, 12Port can use:

  • PowerShell for Windows
  • SSH-based scripts for Linux/Unix and other SSH enabled endpoints or devices
  • Custom scripts for platforms like IBM iSeries or Oracle Solaris

These scripts are executed remotely on the endpoint to perform credential updates.

Password Requirements Password Requirements define the strength and complexity of generated passwords. These settings are available in each Asset Type's or Asset's configuration and allow administrators to enforce:

  • Minimum/Maximum length
  • Upper/lowercase characters
  • Special characters
  • Numeric characters, and more

These policies are inherited by all assets created from that type unless explicitly overridden on an individual asset.

Asset Tasks An Asset Task brings all components, Type, Script, Password Requirements, and Schedule, together. It defines:

  • What script to run
  • When to run it (e.g., scheduled, on-deman, user events)
  • Which assets to apply it to
  • What password complexity rules to follow

Each task can be inherited from the Asset Type or customized per asset.

Configuring Credential Rotation Jobs

By default, credential rotation is ready to use for common accounts like Windows, Linux (accounts or SSH keys), Entra ID, Solaris, and more.

Default Rotation (No Configuration Required)

After an Asset is created, a user can execute an on-demand reset without making any changes to this default configuration.

For example, if a local Windows account needs to be support credential rotation:

  1. Create a new Windows Host asset and populated the required fields.
  2. From the Asset View page, use the option Execute > Windows Password Reset by Account Itself
  3. Open the Reports > Jobs report to review the result.

Windows Default Job Execution

No additional configuration is required unless customization is needed.

Optional Configuration

Inheritance
Tasks and password rules are inherited from the parent Asset Type. To break inheritance and customize these for a specific asset:

  1. Open the Asset’s View page.
  2. Navigate to Manage > Tasks or Manage > Password Requirements.
  3. Click Make Unique to override the inherited settings.

Unique Password Requirements
If a particular asset needs stronger or weaker password rules than those inherited from the Asset Type:

  1. Go to Manage > Password Requirements from the asset view.
  2. Customize the rules for that asset only.

This does not affect other assets of the same type.

Execution Type (On-demand, Scheduled, or Event-Based)
You can adjust how rotation jobs are triggered:

  • On-Demand: Manually triggered via UI or API
  • Scheduled: Run at defined intervals
  • User Event: Triggered by specific user actions (e.g., password view)

To customize:

  1. Open the Asset View page
  2. Navigate to Manage > Tasks
  3. Adjust the Trigger, as needed.

Scheduled Execution

Runs automatically based on a defined schedule.

To configure:

  1. Go to Manage > Tasks from either Asset Type or a unique asset with broken inheritance.
  2. Click Actions > Edit.
  3. Set Trigger to Schedule.
  4. Set a Start At date.
  5. For Schedule, use the Schedule Builder to create a cron-like expression.
  6. Click Save.

Scheduled Execution Example

Example: Rotate credentials every Friday at 01:00 (X X 1 ? * FRI)

User Event Execution

Triggered by specific user or event log actions, such as updating an asset or viewing a password.

To configure:

  1. Go to Manage > Tasks and click Actions > Edit.
  2. Set Trigger to one of the following:
    • After Create: the task is executed after the asset is created
    • After Update: the task is executed after the asset is updated
    • After View: the task is executed after one of the asset secret fields is open for access, like Password
    • Completed Unlock Request: the task is executed after an unlock request workflow is completed.
    • Completed Access Request: the task is executed after an access request workflow is completed.
  3. Set a Delay (in minutes), if needed. This value delays the task execution by then number of defined minutes. For example, rotate the password 60 minutes after it is viewed.
  4. Click Save.

User Event Execution Example

Example: Rotate password 60 minutes after it is viewed.

On-demand Execution

Triggered manually by a user or programmatically via API.

To configure:

  1. Go to Manage > Tasks and click Actions > Edit.
  2. Set Trigger to Interactive.
  3. Optionally define a Delay. Use zero value for no delay.
  4. Click Save.

On-Demand Execution Example

Example: Rotate the credential after manual execution.

Auditing and Jobs Reports

All rotation jobs, regardless of how they’re triggered, are logged in the Jobs Report. This report is accessible to users with proper permissions and shows detailed results of each job.

Accessing Job Reports

The Job Report can be accessed in two primary ways: * From an Asset: To view all executed jobs associated with a specific asset, navigate to the asset’s View page, then go to Reports > Jobs. * Global View: To view all executed jobs across the environment, regardless of asset, use the global navigation: Reports > Jobs from the left-hand menu. Requires the Administrator or Auditor site role.

Regardless of access path, the information displayed in each entry remains consistent.

Report Columns

The Jobs Report includes the following columns. Jobs results are sorted by the Started column by default, either in ascending or descending order:

  • Started: Timestamp when job execution began
  • Completed: Timestamp when job execution finished
  • Next: Time of next scheduled job (if recurring). Note that all historical job executions for the same task display the same value for the next run time.
  • Asset: Asset associated to the job. The asset contains remote host for the job execution as well as the connection credentials.
  • Host: Host field from the associated job asset. Typically, this is the host where the job was executed in case of the remote job.
  • Task: Task associated with the job. A task contains information about the connection protocol for the job execution, the script, the result parser and the method to access job execution environment (such as host names, credentials and options).
  • Status: Job status is the state of the job execution progress. The system supports the following job statuses:
    • Started, Completed, Warning, Failed
  • Trigger: Task trigger is the condition prescribing when the task script should be run. The system supports the following triggers:
    • Interactive: the task is executed immediately by a user or machine using GUI or API system interface
    • After Create: the task is executed after the asset is created
    • After Update: the task is executed after the asset is updated
    • After View: the task is executed after one of the asset secret fields is open for access, like Password
    • Run At: the task is executed at the specified time
    • Schedule: the task is executed according with the specified schedule
  • Run Type: Run type is the way this job execution was triggered. The system support the following run types:
    • Interactive: the job was started by a user using GUI or a script using an API
    • Event: the job was started in response to a system even such as updating an asset
    • Schedule: the job was started by the scheduler
  • User: User who interactively triggered the job.
  • Site: A Site from the tenant Site hierarchy that originated the event.
  • Exit Code: Exit code of the script after execution on the endpoint.
  • Result: Raw job execution result.