Updating & Rotating Credentials
Sooner or later every credential needs to change: a vendor forces a rotation, a staff member with key access leaves, or your security policy says keys rotate every 90 days. This chapter covers what…
Written By Christopher Scaminaci
Last updated 3 days ago
Sooner or later every credential needs to change: a vendor forces a rotation, a staff member with key access leaves, or your security policy says keys rotate every 90 days. This chapter covers what that looks like in StackJack.
Which kind of rotation are you doing?
Vendors fall into two groups, and the safe order of steps is different for each. Check your connector's own guide, or the vendor's console, before you start.
Where the vendor lets two credentials exist at once
Several vendors let you hold a second, named credential alongside the one in use — Atera and AlertOps are two the guides call out. There, rotate with no gap at all:
- Create the replacement in the vendor product. Copy it right away; most vendors show a secret only once.
- Update StackJack: Connectors → the connector's card → Update, enter the new values, and Save.
- Test the connection and confirm the card reads Valid.
- Revoke the old credential in the vendor, and only then.
Where regenerating replaces the old credential immediately
Other vendors have one credential per integration, so regenerating it kills the old one the moment you press the button. N-central JWTs and Huntress key pairs work this way. There, the old key StackJack holds stops working immediately, so treat it as one operation: generate, then update StackJack straight away. StackJack's background health checks will notice the failures, mark the connector Invalid, and — after repeated failures — auto-disable it (see Connector Health & Auto-Disable).
If you were too slow and the connector got auto-disabled in the meantime, that's fine: Update Credentials, then Re-enable on the card.
What the Update dialog does (and doesn't) show
- Non-secret settings (instance URL, region, auth method) are pre-filled so you can change just what you need.
- Secrets are never displayed — stored secret values are not echoed back into the dialog, ever.
- Many connectors support leave-blank-to-keep on specific fields, and each one says so right in the dialog — once a value is stored, the field's placeholder or helper text reads something like "leave blank to keep the stored value". The dialog is authoritative; the examples below are not a complete list.
- ConnectWise Automate — the Authenticator Secret field shows "(currently configured — leave blank to keep)" when a seed is already stored, so you can update the Integrator username or password without re-typing it. A separate control explicitly clears the stored authenticator secret when the account no longer uses MFA.
- N-able N-central — leave the JWT field blank to keep the current token (useful for URL-only updates).
- Cisco Duo — the Admin API and Auth API secret keys each keep their stored value when left blank, so you can update one application's key pair without re-typing the other's secret.
- Keeper Security — the Partner Secret, the MSP signing secret, and the SCIM token each keep their stored value when left blank, so you can rotate one surface at a time.
- TD SYNNEX — the ION refresh token and the ECExpress password each keep their stored value when left blank.
- UniFi — the cloud API key and the optional Mobility and direct-controller keys each show a "Stored — leave blank to keep it" placeholder once a value exists, so you can change the controller URL or add a second key without re-pasting the others. Because a blank field keeps the key here, removing a revoked cloud key needs the dialog's explicit clear control rather than an empty field.
- Where a secret field offers no such hint, plan to re-enter it when you update.
Rotating an OAuth app secret (HaloPSA / NinjaOne)
If your connector runs in OAuth mode and you rotate the OAuth application's client secret in the vendor:
- Update the shared credential on the Connectors page with the new client secret.
- Team members' personal connections are usually updated for you. StackJack copies the new app configuration onto each member's per-user credential and keeps that member's own sign-in, so in the normal case — same server, only the client secret changed — nobody has to re-authorize.
- It is not guaranteed for every member. A member StackJack could not update is left on the old configuration, their card flips to Re-authorize Required, and either they re-authorize or StackJack support re-runs the copy for them. Check the personal sign-ins after a rotation on a large team.
- Changing the server address is not a secret rotation. If the save moves the connector to a different HaloPSA or NinjaOne host, StackJack deliberately refuses to carry members' existing sign-ins across: their tokens were issued by the old host. Everyone signs in again against the new address.
- Changing scopes does not re-consent anyone. The new scope list is copied onto each member's credential, but each member's stored sign-in still carries what they approved originally. Expect to ask members to re-authorize before a widened scope works for them.
- Your own connection's refresh token is preserved across a configuration-only update, so changing the app secret does not by itself break an established OAuth connection.
Rotation quirks worth knowing
- Secrets shown once: many vendors (Datto RMM, Huntress, IT Glue, Syncro, Addigy, Liongard, and others) display a new secret exactly once at creation. If you lose it, generate a new one — don't hunt for the old value.
- Pax8 secrets are shown once: if the Client Secret for your Pax8 API Application is lost, generate a replacement in the Pax8 developer portal rather than hunting for the old value, then update StackJack. See Connect Pax8.
- Autotask re-runs zone discovery on every save: the API username drives it, so a mistyped username aborts the update instead of storing a credential that points at the wrong datacenter. Rotate the API user's Secret in Autotask, then re-enter the integration code, username, and new Secret together. See Connect Autotask PSA.
- The ConnectWise client ID rarely changes: it identifies the integration, not your data access, so it stays put while you rotate the PSA API member's keys or the Automate Integrator password. A connection that uses StackJack's client ID has nothing to rotate here; one that uses your company's own client ID re-enters it with the rest of the form on update, because it is not a leave-blank-to-keep field. See Connect ConnectWise PSA and Connect ConnectWise Automate.
- Regenerating invalidates the old credential on many platforms (Huntress key pairs, N-central JWTs). Treat rotation there as an immediate, two-step operation: generate, then update StackJack. It is not universal — where the vendor supports a second named credential, use the create-update-test-revoke order above instead. The connector's own guide says which applies.
- N-central personal tokens: each member rotates their own JWT from the Connectors page → personal sign-ins → Update JWT.
- Addigy tokens can't be edited after creation — if you need different permissions, create a new token and update StackJack with it.