Our krbtgt password hasn’t changed since 2012. What’s the safe way to handle it?

That is a long time to leave it unchanged, so I’d plan a controlled rotation rather than treating it as an emergency by default. First confirm domain controller replication is healthy, check for any unusual Kerberos dependencies, and make sure you have a recovery plan for Active Directory.

For a routine maintenance rotation, follow current Microsoft guidance and your organization’s change process. The second reset is generally delayed so the first change can replicate and tickets signed with the older key can age out. A commonly used conservative interval is about a day, but verify the applicable ticket lifetimes and guidance for your environment instead of relying on a fixed interval.

Don’t confuse resetting krbtgt with changing a machine account password. A laptop being offline during the waiting period does not, by itself, mean its domain trust will break. Still, make sure the domain controllers have replicated successfully before proceeding, and schedule the work so you can respond if a service has a Kerberos issue.

Cloud identity synchronization is a separate concern from the domain’s Kerberos keys. I’d include the remaining domain-joined servers and any systems that authenticate against the domain in the review.

One reset and two resets serve different purposes. A second reset is part of the usual procedure when you need to invalidate tickets that could still be signed with the prior key, especially during a suspected compromise. For routine rotation, follow the current vendor procedure and don’t assume an extra reset is harmless or universally required.

Also consider recovery implications. Older system-state backups may be harder to use after key changes, so check your forest recovery plan and backup handling before making this a recurring schedule.

I’d raise it with the team as a maintenance and security hygiene issue, not as proof that something is compromised. Agree on an owner, validate replication and backups, document the sequence, and use a well-reviewed procedure that can check domain health before each step. Afterward, monitor authentication and service logs for problems.

Since the password is from 2012, check whether any legacy systems or encryption settings could be affected by modernizing the key material. Don’t make unrelated domain functional-level changes part of the same change unless they have been separately assessed.