Reset them when the account is old, never rotated, or clearly lacks AES key generation in the target domain. A controlled reset is the practical way to generate the key material that Kerberos needs after migration, but it should happen before cutover, not after applications start failing.
When should a migrated account be reset before an AES cutover?
Reset the migrated account before cutover when the account is old, has never been rotated in the target domain, or does not clearly have the AES key material Kerberos expects after migration. The point is to generate fresh keys in a controlled way while you still have change windows, validation time, and rollback options. Waiting until applications break turns a planned identity action into an outage response.
What makes the reset a control step, not just a cleanup task?
A migrated account can look valid on paper and still fail in practice if its key material, encryption settings, or account history do not line up with the target domain’s Kerberos expectations. In that case, reset is the mechanism that re-establishes a usable authentication state. It is less about fixing “bad” accounts and more about ensuring the migrated identity can actually obtain tickets and authenticate after the move.
That is why reset timing matters. If you reset after the cutover, you risk discovering the problem only when services begin failing. If you reset beforehand, you can verify that dependent systems, scheduled jobs, and applications are using the refreshed credentials or service mappings before the legacy path is removed.
Which accounts deserve the fastest reset decision?
The highest-priority candidates are stale accounts, accounts with unclear rotation history, and accounts that were carried forward from a legacy domain without a documented key-generation event. Those are the accounts most likely to fail silently during migration because their state is inherited, not re-established. A reset is also a strong signal to separate old operational history from the new domain lifecycle.
For service and application accounts, the question is not whether the account name survived migration, but whether the authentication material behind it survived in a usable form. If the answer is uncertain, treat that uncertainty as a cutover risk. A controlled reset is usually the safer choice than trying to preserve legacy credentials across domains and hoping Kerberos accepts them unchanged.
Risk and Threat Considerations
Migration failures around account reset usually surface as authentication outages, but the deeper risk is inconsistent trust state between the old and target domain. An account that was not re-keyed cleanly can create broken logons, failed service starts, and hard-to-diagnose dependency failures across applications that still assume valid Kerberos material.
Failure mechanism: The account carries forward stale or incomplete key material, so the target domain cannot issue or accept the expected Kerberos authentication flow after cutover.
Impact: Applications, jobs, and services can fail in waves, and the repair effort becomes slower because teams must distinguish credential state problems from application defects while production is already affected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers credential lifecycle and rotation needed for migrated account reset decisions. |
| IA-9 — Service Identification and Authentication | Applies when migrated service or application accounts must authenticate after domain cutover. | |
| AC-2 — Account Management | Supports lifecycle handling of migrated accounts, including reset, review, and removal of stale access. | |
| Recommendation — Rotate or replace authenticators before cutover and verify the new credential state works in the target domain. Validate service authentication paths after reset so dependent systems can obtain access without legacy keys. Review migrated accounts for stale or uncertain state and reset or retire them before production cutover. | ||
Practitioner Guidance
Decision rule: If the migrated account is old, unrotated, or its AES state cannot be proven in the target domain, reset it before cutover and validate the new authentication path while both environments are still available. Do not wait for first-use failure as the trigger.
What to verify: Confirm which systems depend on the account, whether the account is interactive or service-facing, and whether any scheduled tasks, integrations, or applications still reference the pre-migration credential path. The reset is only safe when those dependencies are known and tested.
Practitioner takeaway: The safe cutover pattern is to prove the new key state before the domain move is treated as complete, because post-cutover resets convert a controlled migration into an incident recovery exercise.
Related resources from NHI Mgmt Group
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- Why do identity teams miss privileged accounts during reviews?
- What breaks when RC4-only Kerberos accounts are migrated into AES-default Active Directory domains?
- How should security teams prove identity controls during cyber insurance renewal?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org