Agent gets offline on navigating to Cluster A>Cluster B>Cluster A with Elastic Defend when replace token is used.

[amolnater-qasource]

Kibana version:

VERSION: 9.2.0 BC3
BUILD: 91544
COMMIT: 0c40a02e995201d9395473309adda6cd020d56ca
Artifact: https://staging.elastic.co/9.2.0-46faaca4/downloads/beats/elastic-agent/elastic-agent-9.2.0-linux-x86_64.tar.gz

Preconditions:

1. 9.2.0-SNAPSHOT Kibana cloud environment should be available.
2. An agent should be installed with Agent policy having Elastic Defend integration and tamper protection disabled.

Steps to reproduce:

1. Navigate to Agents tab on Cluster A.
2. Click Actions>Migrate Agent and add new Fleet Server URL and enrollment token for the agent policy not having Elastic Defend integration.[Cluster B]
3. Add a Replace token say: Test123, Click Migrate Agent.
4. Observe agent is migrated to the new cluster[Cluster B without Elastic Defend] and Agent remains Healthy.
5. Now Migrate it to the same cluster A to the agent policy having Elastic Defend integration with same Replace Token: Test123.
6. Observe agent gets stuck in updating state and then gets offline.

Expected behavior:
Agent should get Healthy on navigating to Cluster A>Cluster B>Cluster A with Elastic Defend when replace token is used.

What's working fine:

• Agent ID remains same for the migrated Agents.
• Issue is not reproduced when Replace token field is not used.

Agent Logs:

elastic-agent-diagnostics-2025-10-10T11-34-38Z-00.zip

Agent JSON:

ip-172-31-80-190-agent-details.json

Screen Capture:

Screen.Recording.2025-10-10.at.4.57.47.PM.mov

Screen.Recording.2025-10-10.at.5.01.02.PM.mov

Screen.Recording.2025-10-10.at.5.04.53.PM.mov

Related Feature:
elastic/kibana#217619

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[amolnater-qasource]

@muskangulati-qasource Please review.

[amolnater-qasource]

FYI @michalpristas

[muskangulati-qasource]

Secondary review is Done for this ticket!

[michalpristas]

was the agent enrolled to cluster A with the enrollment key in the first place?
if not, migration will be broken on id already used, this is by design and not a bug

[amolnater-qasource]

Hi @michalpristas
Thank you for looking into this issue.

was the agent enrolled to cluster A with the enrollment key in the first place?

Did you mean while installing the agent for first time we have used replace token?
For this, no we didn't install the agent with replace token initially.

• We have installed the agent using: sudo ./elastic-agent install --url=xxx --enrollment-token=xxxxx

Please let us know if anything else is required from our end.
Thanks!

[michalpristas]

yes to be able to get it back with the same id it needs to be installed with the same replace token for the first time as well

[ebeahan]

if not, migration will be broken on id already used, this is by design and not a bug

@michalpristas sounds like this holds true still? Anything that remains to test out here?

[amolnater-qasource]

Hi @michalpristas

Thank you for the update.

We have revalidated this issue again by installing agent with --replace-token="test99".

Then migrated from Cluster A[With Defend]>Cluster B[Without Defend] and then back to Cluster A[With Defend] using same replace token and found it still reproducible.

• Agent gets offline after being stucked in Updating state for too long.
• Issue is also reproducible on Migrating with only System integration.

Screen Capture:

Diagnostics:

elastic-agent-diagnostics-2025-10-30T08-18-10Z-00.zip

ip-172-31-84-202-agent-details.json

Artifact Link:
https://snapshots.elastic.co/9.3.0-5f715419/downloads/beats/elastic-agent/elastic-agent-9.3.0-SNAPSHOT-linux-x86_64.tar.gz

Please let us know if we are missing anything here.
Thanks!!