Organization Key Revocation After Deletion – Huntress Support

Team: Huntress Managed Endpoint Detection and Response (EDR)
Product: Huntress Platform
Summary: When you delete an organization in the Huntress platform, Huntress automatically revokes the associated organization key to prevent unexpected endpoint billing.

Before Deleting an Organization

Before deleting an organization, find and remove or update any deployment automation that still references the organization key. Common locations include:

Group Policy Objects (GPOs), startup scripts, logon scripts, and scheduled tasks
RMM policies, monitors, components, and installation scripts
PowerShell or batch deployment scripts
VDI or golden-image build processes
Shadow-copy or backup-based deployment workflows
PSA or other third-party automation
API or infrastructure-as-code workflows

If the client is being moved to another organization or Huntress account, update the deployment to use the destination organization’s current key instead of continuing to use the deleted organization’s key.

Deleting an organization is permanent and can affect the Huntress Agents and other services associated with it. For general deletion guidance, see Add, Rename or Delete Organizations.

What Happens After Deletion

The deletion confirmation explains that the organization key will also be revoked. After deletion:

The deleted organization key is recorded as revoked for the original Huntress account.
New Huntress Agent registrations using that account and organization key are blocked.
Huntress does not recreate the deleted organization when a registration attempt is blocked.
Registration attempts against the revoked key can be shown in the Account Settings experience.
When blocked attempts occur, partner administrators receive a weekly summary showing the deleted organization, affected hostnames, and the number of attempts from each hostname.

A weekly summary is sent only when blocked registration attempts occurred during the reporting period. If no attempts occur, no empty summary is sent. Notifications continue while systems continue trying to use the revoked key. Silencing the notifications does not unblock the key or stop the deployment from attempting registration, so the old automation should still be removed or updated.

Troubleshooting a Blocked Registration

If a Huntress Agent will not register after an organization was deleted or moved, complete the following checks:

1. Verify the keys being used

Confirm the following values:

The account key
The organization key used by the installer or deployment automation
The Huntress account and organization where the Huntress Agent is expected to appear

The organization name is a display value. The organization key is the value used during Huntress Agent registration, so confirm the key in the actual installer, script, RMM policy, image, or other deployment mechanism. For more information about keys, see Using Account Keys, Organization Keys, and Agent Tags.

2. Check for stale deployment automation

Search the affected environment for the deleted organization key. Pay particular attention to GPOs, scheduled tasks, RMM policies, PowerShell or batch files, VDI images, backup or shadow-copy workflows, and API-based provisioning.

If the endpoint should remain protected, update the deployment to use the correct current account and organization keys. Do not continue retrying the deleted organization key.

3. Review blocked registration activity

Use the revoked-key information in Account Settings, when available, to compare the affected hostnames with the systems still receiving the old deployment. The weekly summary can also help identify where the stale automation is running.

These entries are generally offboarding or deployment cleanup signals. They do not, by themselves, indicate malicious activity.

4. Contact Huntress Support when the deletion was accidental

There is no partner-facing self-service option to un-revoke an organization key in the initial release. Contact Huntress Support if:

An organization was accidentally deleted.
A customer move requires temporarily restoring the old key.
A legitimate deployment is blocked because the wrong organization was deleted or the key was revoked incorrectly.

Support will verify the Huntress account and organization key before restoring access. Remove or correct stale deployment automation whenever possible before the key is restored; otherwise, old systems may register again and recreate the billing issue the feature is intended to prevent.

When contacting Support, include:

Huntress account name or account ID
Deleted or expected organization name
Organization key used by the deployment
Affected hostname or hostnames
Approximate time of the registration attempt
Deployment method, such as GPO, RMM, VDI, PowerShell, or API

Frequently Asked Questions

Can I manually recreate the deleted organization with the same key?

Not while that key is actively revoked in the same Huntress account. Use the correct current key for a new organization, or contact Huntress Support if the organization was deleted accidentally and the original key must be restored.

Does revocation affect another Huntress account that uses the same key value?

No. Revocation is scoped to the account that owned the deleted organization. Another Huntress account can use the same key value.

Does revocation uninstall existing Huntress Agents?

Revocation is a registration control. It blocks new registration attempts that use the revoked account and organization key; it is not an automatic uninstall action for already enrolled Huntress Agents.

Can I unrevoke the key myself?

The initial release does not provide a partner-facing unrevoke workflow. Contact Huntress Support with the account, organization, and deployment details so the request can be reviewed.

Is this the same as rotating an account key?

No. This feature is specific to the organization key associated with a deleted organization. Account key rotation is a broader and more disruptive action and is not the normal solution for this scenario.

In this Article