Rollback Plan
Rollback is defined for each migration wave before production changes begin. The immediate objective is to restore the affected application or enrollment service to a known working state while the team investigates the PKIaaS issue. The rollback decision, owner, and trigger are recorded in the migration plan.
- Pause the affected wave. Stop further certificate replacement or enrollment policy changes when a defined validation check fails. Record the affected systems, error, time, and most recent successful configuration.
- Restore the prior certificate and binding. Where the previous certificate remains valid and its private key is available, reinstall or reselect it on the affected server, device, or application. Restore the previous TLS binding, authentication setting, or application configuration as applicable.
- Restore the prior enrollment path. If the issue affects automated enrollment, revert the pilot Group Policy, template assignment, or integration setting for the affected group. Keep the old CA available to process requests while that group is rolled back.
- Verify service recovery. Test the application or authentication flow, certificate chain, and revocation check from the same type of client that detected the failure. Confirm recovery with the application owner before closing the rollback change.
- Investigate and retest. Preserve relevant gateway, CA, portal, client, and application logs. Correct the cause in a test or pilot group, then repeat the full validation checks before rescheduling the wave.
- Reassess rollback after decommissioning. Once an old CA or its key material has been retired, returning to it may no longer be possible. The decommissioning plan therefore requires a separate recovery strategy and explicit customer approval before the old issuance capability is removed.