Credential Lifecycle and Recovery

Credential incidents are easier to contain when each lifecycle action has one meaning. Choose the narrowest action that meets the operational need, then verify both LyftData and the external provider.

Applies to

Encrypted credential delivery is a Beta Enterprise capability for single-node, distributed-worker, and hybrid deployments. Plain-secret lifecycle is available in all editions. Confirm the installed edition and operation metadata before following an automated recovery path.

Choose an action

Action	LyftData effect	Use it for
Rotate	Replaces secret or token material while retaining the logical record	Planned replacement or expanded provider scopes
Disable	Pauses activation and runtime use while preserving metadata and history	Investigation or temporary containment
Revoke	Clears current credential material and runtime records; activation is required again	Suspected compromise or provider grant change
Delete	Removes the record after dependencies are cleared	Permanent retirement

Disabling, revoking, or deleting in LyftData does not necessarily revoke the external provider’s token, secret, session, or consent. Perform the matching provider-side action as part of the same incident or change record.

Planned rotation

1. Inventory job bindings, allowed workers/groups, and provider scopes.
2. Create or activate replacement material.
3. Verify a non-destructive operation through the intended worker.
4. Monitor dependent jobs through at least one normal execution window.
5. Revoke the previous material at the provider.
6. Record the new owner, expiry, and next rotation date.

OAuth credentials using a supported server refresh strategy can refresh access tokens without a redeploy. Refresh remains subject to provider policy, refresh token validity, network reachability, and the credential’s enabled state.

Emergency containment

1. Disable or revoke the credential in LyftData.
2. Revoke or disable the grant at the external provider.
3. Remove affected job bindings and allowed-worker access where needed.
4. Confirm new runtime fetches fail closed.
5. Inspect logs, activation history, and provider audit records.
6. Create fresh material and reactivate only after the cause is understood.

Prefer disable for a reversible pause and revoke when current token material must be cleared. Delete is not the normal first response because it removes the record needed for investigation.

Master-key failure

Credential state is encrypted using an installation master key. If the server cannot load the expected key:

1. stop write activity;
2. restore the matching master key from your protected backup;
3. restart and verify that redacted credential metadata and activation state load normally;
4. run a bounded credential and worker delivery check; and
5. plan a controlled rotation after recovery.

Do not generate a new key and expect it to decrypt state protected by the lost key. Do not edit encrypted database fields.

Headless deployments should provide the credential, variables, and settings master keys through the secured service configuration described in Configuration. Back up keys separately from the staging directory and restrict access to both.

Recovery evidence

A complete recovery record should include:

• the credential ID and affected jobs/workers, without plaintext material;
• the action taken in LyftData and at the provider;
• the activation or rotation result;
• worker runtime-readiness evidence;
• a bounded job result and provider-side confirmation; and
• any remaining tokens, sessions, or hosts that still require action.

Redact tokens, secrets, authorization codes, client secrets, and private keys from tickets, screenshots, logs, and support bundles.