Britive platform release 2026.04.01 is now live in production.

Creating and Managing Secrets

Prev Next

Adding a secret

  1. Log in to Britive.

  2. Click on System admin->Secret Management->Britive Vault.

  3. Select the node where the secret needs to be created.

  4. Click on the Secrets tab and click the Add Secret button or select Add Secret from the overflow menu of a particular node.

  5. Enter the following on the Add Secret page:

    1. Enter the Secret Name.

    2. Enter the Description (optional).

    3. Impersonation Settings: Enable this setting to grant service/AI identities permission to act on behalf of users or tags.

    4. Category:

      1. Static: A user must rotate a secret manually. Based on the rotation configuration, the administrator is notified about the rotation.

      2. Dynamic: The Secrets Manager automatically rotates the secret in the target resource. Secrets with password fields are only allowed as dynamic secrets.

        1. Secret Rotation Interval (in days): The secret is rotated automatically after the secret rotation interval.

    5. Select the Secret Type from the drop-down list of secret templates. For more information about creating a secret template, see Creating and Managing Static Secret Templates.

    6. Enter the secret details that are based on the selected secret type. For Example,

      • If the secret type is selected as GenericWebApp, you must enter the URL (optional), Username, and Password as the secret details.

      • If the secret type is selected as a file templateyou need to upload the file as a secret. The file size should be less than or equal to 400 KB.

      • If the secret type is based on a template using an OTP Seed, you need to enter either a QR code or a Setup Key. This is used only in case of applications that have configured MFA authentication. You can select one of the following:

        • QR Code: Upload a file containing a QR code. A QR code is acquired from the source application when MFA authentication is enabled. The file size limit is 400 KB.

        • Setup Key: Enter the setup key value. 

      • If the secret type is based on a template using recovery keys, you need to enter the recovery keys/backup codes generated by the source application.

      • If the secret type is based on a template using the account field configured as Discoverable, you get a list of resources to select. Once you select a resource, a list of accounts is displayed. If Discoverable is not selected, you have to manually enter the account name.

    7. Enter or generate the Password. You have the option to let the system generate a password, or you can enter a password. The password should strictly match the criteria specified in the password policy of the selected secret template.

    8. Click Save.

Managing Secrets

You can edit secret details, move secrets to a different node, or delete secrets.

  1. Log in to Britive.

  2. Click on System admin->Secret Management->Britive Vault.

  3. Click on the Secrets tab.

  4. Select the secret and choose the Action:

    1. Manage Secret:

      • Edit:

        • Update the secret details, including the secret name. You can edit the secret details based on the selected secret template. For example, if you are using a file as a secret, you can download the secret file. 

        • If step-up verification is configured while configuring the secrets policy, you must select the preferred authentication method to view and edit the secret. For more information about configuring step-up verification for a secrets policy, see Secrets Policies. If WebAuthn authentication is configured, a user is prompted with a WebAuthn verification popup. In the same way, if only the OTP is configured, it prompts for the OTP. To register a verification device, see User Settings

        • For WebAuthn: Click Edit Secret with WebAuthn and complete the verification process on your registered device.

        • For OTP: Enter the OTP from the authentication app and click Edit Secret with OTP.

        • Enable Allow Impersonate under Impersonation Settings to grant service/AI identities permission to act on behalf of users or tags.

          Note:

          Renaming or moving a secret to a different node/path cancels the pending approvals. You need to send an approval request again to gain access.

        • Click Generate to generate a new password and click Save. Saving the secret triggers the rotation and asks the user if this secret needs to be synchronized with the target resource.

        • Click Save as Version to create a new version of the secret data. If the secret is configured with TargetDetails, the user is presented with an option to either synchronize the secret with the target resource or proceed with saving it without synchronization.

        • Reset: Reset the secret details. 

      • Delete: Click Delete to delete the secret.

      • Rotation Details:

        • Targets:

          • Select the rotation template configured in the resource type.

          • Click View Template to view the contents of a template.

          • Click Add Values to Variables to map secret fields. The account name, which is configured in the secret, is mapped to the script variable.

        • Notification:

          • Add notification medium: Click Add Notification Medium to select a notification medium. The notifications are sent after secret rotation.

          • Users: Click Select Users and add one or more members for this policy.

          • Tags: Click Select Tags and add one or more tags for this policy.

      • Rotation History: Displays the history of rotation events for the selected secret.

      • Versions: Displays the history of secret versions created for the selected secret.

    2. Delete Secret: Delete the secret.

    3. Move Secret: Moves a secret from its current node to a different node or path. Select the secret you want to move and click the Move Secret action. On the Move Secret window, select the desired node and click the Move button. Only policies directly associated with the secret are transferred to the new node. Any inherited policy accesses from the original parent nodes are discarded, and the secret inherits access permissions from the new parent node(s), if applicable.