Best practices for managing password desynchronization
This article describes the scenarios where password desynchronization is most likely to occur and the actions you can take in Cerby to prevent it.
Cerby securely manages and rotates application passwords for users. Password desynchronization occurs when Cerby stores one password, but the target application expects a different one. When this happens, users may experience login failures, and automated password rotation may not work as expected.
The following scenarios describe where password desynchronization is most likely to occur and the actions you can take in Cerby to prevent it:
The following sections explain each scenario, its impact, and the suggested steps to recover from and prevent it.
User deactivated and later reactivated
When a user is deprovisioned, whether removed from the identity provider (IdP) or directly from a downstream application, the affected application may disable the account or invalidate the password based on its own policies or configuration. By design, Cerby does not automatically restore a user's original accounts when they are reactivated, because their access grants may have changed.
Impact
Users cannot log in after reactivation.
During the user's deactivation, the downstream app may have disabled or suspended the account natively. If Cerby later attempts to run an automated password rotation job, it may fail because the account is no longer accessible.
The downstream application may invalidate the previous password because of inactivity or its own security policies. Because Cerby's automated rotation process typically requires the current stored password to set a new one, the application may reject the attempt as an invalid login.
How to recover
A workspace Admin, Super Admin, or account Owner can take the following actions:
Trigger password rotation after user deprovisioning to ensure Cerby retains the latest password and the deactivated user is unable to log in.
Confirm the user account is active in the app.
Re-run access provisioning workflows.
IMPORTANT: If Cerby's password rotation fails for the account, contact [email protected].
Prevention
Treat user reactivation as a new access event.
Always rotate or verify passwords after offboarding and onboarding users.
Access revoked without credential cleanup
This scenario occurs when a user's access is removed in Cerby, but the downstream application account or password remains active. If access to a credential is removed in Cerby without rotating or disabling the downstream credential, that credential becomes "unmanaged". Cerby no longer rotates or monitors the password, and native changes may occur without Cerby's involvement.
This scenario might typically happen if:
An application has an automatic password expiration policy, such as a 90-day password expiration policy, that continues while the account is unmanaged.
The account no longer has a designated Owner to manage its lifecycle.
Impact
Cerby attempts to use the last known password on file, but the downstream application rejects it because the password was changed natively while Cerby was no longer managing it.
Users may have access to the account but still be unable to log in.
Support requests may increase.
How to recover
Account Owners must take the following actions:
Perform a complete password reset in the downstream application, then update the password in Cerby.
Re-onboard the credential if required.
Validate the login before restoring access broadly.
Prevention
Align access revocation with credential lifecycle actions.
Use standardized offboarding workflows.
Ensure accounts always have an Owner. Workspace Admins can use the Security Hub to identify orphaned accounts, assign new Owners, and help keep passwords valid.
Manual password changes outside of Cerby
This scenario occurs when an administrator changes the password directly in the downstream application instead of through Cerby. As a result, Cerby stores an outdated password, which may later cause conflicts during login or rotation.
Impact
Login failures.
Unexpected password resets.
Rotation conflicts.
How to recover
Account Owners must take the following actions:
Reset or re-sync the password using Cerby.
Update the password manually in Cerby.
Confirm Cerby is managing the credential again.
Prevention
Restrict manual password changes in the app, where possible, using Cerby's app settings restrictions to prevent external password modifications made directly in the app.
Avoid changing application passwords outside of Cerby whenever possible.
Educate admins and users to avoid manual password resets.
Best practices for preventing password desynchronization
To reduce password desynchronization, use your identity provider (IdP) or identity governance and administration (IGA) solution to manage identity lifecycle events, and use Cerby to manage and rotate downstream application passwords.
Follow these best practices:
Use standardized user offboarding and re-onboarding workflows through the appropriate IdP or IGA solution.
Treat any instance of re-adding, reactivating, or restoring access as a potential password reset event.
Rotate or verify passwords after major admin and account Owner changes.
Configure Cerby's app settings restrictions to prevent external password modifications made directly in the app.
Regularly monitor password health, rotation logs, and login success.
Enable Cerby to rotate passwords after users are deprovisioned from the IdP.
Last updated
Was this helpful?