For collectors

How to change a Hedera account key

Replace the key on a Hedera account with one update signed by the old key and the new one. The account ID, HBAR, NFTs and allowances stay where they are.

Content reviewed on

A locksmith's workbench at night where a person swaps the key on a lit vault plate marked with an account number, while the vault stays closed and full, SentX pixel art

A Hedera account key is changed with one account update transaction, signed by both the current key and the new key. Once it reaches consensus, only the new key can sign for the account. The account ID, the HBAR balance, the tokens, the NFTs and the allowances all stay where they are, because on Hedera the account ID is not derived from the key.

It is also a change you cannot undo without the new key. Practise once on testnet and keep the old key until the update is confirmed.

What you need

  • The account ID, such as 0.0.12345.
  • The current private key or recovery phrase, in a wallet or a script that can sign with it.
  • The new key, already created and backed up offline.
  • A little HBAR in the account for the network fee.

Why change the key

  • The key may be exposed. A recovery phrase typed into a website, stored in a cloud note or seen by someone else is no longer private. Replace it before anyone uses it. If the key may already be in someone else's hands, act first and practise later. After the change, check the account's allowances and remove any you did not give, because a key change does not cancel them. Step 5 shows where.
  • You want more than one key. A threshold key, such as any two of three keys, means one lost or stolen key is not enough to move funds.
  • A post-quantum key type arrives. Hedera targets 2027 for a post-quantum account key type. Moving to it will be the same kind of update. Is HBAR quantum resistant? has the plan.

What stays the same, and what changes

An account update changes only the fields it sets. A key change sets the key, so everything else about the account stays:

  • The account ID and its HBAR balance.
  • Fungible tokens, NFTs and token associations.
  • Allowances the account has given, including the NFT allowances behind a SentX listing, so listings stay listed.
  • Staking settings, the memo and the automatic association slots.
  • An EVM address set when the account was created. It stays, but it stays tied to the original key (see the safety notes).

What changes is who can sign from now on. The old key, and any wallet or recovery phrase that holds only the old key, cannot sign new transactions. Allowances given before the change keep working, and the change does not sign anyone out of a website.

Step 1: Practise on testnet

Create a testnet account in the Hedera developer portal or in a wallet that supports testnet, and change its key once before you touch mainnet. Testnet HBAR has no value, so a mistake costs nothing.

Result

  • You should now have a testnet account whose key you changed and then used to sign a transfer.

Step 2: Prepare the new key

Create the new key before you change anything, and back up its recovery phrase or private key offline, in at least two places. If your wallet has a rekey feature, it may create the new key for you and show the new recovery details: write them down before you confirm.

For most people the new key should be the same type as the old one. Changing an ECDSA account to an Ed25519 key, or the other way round, affects which wallets and tools can use it.

Result

  • You should now have the new recovery phrase or key written down, and the old one still in your wallet.

Step 3: Change it in a wallet

Support for key rotation varies between Hedera wallets and changes with their releases, so check your wallet's own help pages first.

HashPack documents a rekey feature for Ed25519 accounts under Advanced Tools in its main menu. It creates new recovery details for the account. HashPack does not offer it for ECDSA accounts. Read HashPack's note on key types.

If your wallet has no rekey option, the developer route below does the same thing with the Hedera SDK.

Result

  • You should now see the new recovery details in your wallet, and the account ID unchanged.

Step 4: Or change it with the Hedera SDK

The transaction is AccountUpdateTransaction with setKey. Freeze it, sign it with the current key and the new key, then submit it and read the receipt. This example uses Ed25519 keys on testnet; for ECDSA keys use PrivateKey.fromStringECDSA.

import { AccountId, AccountUpdateTransaction, Client, PrivateKey } from '@hiero-ledger/sdk';

// Read both keys from somewhere safe. Name the key type when you parse a key.
const accountId = AccountId.fromString(process.env.ACCOUNT_ID);
const oldKey = PrivateKey.fromStringED25519(process.env.OLD_KEY);
const newKey = PrivateKey.fromStringED25519(process.env.NEW_KEY);

const client = Client.forTestnet().setOperator(accountId, oldKey);

const tx = new AccountUpdateTransaction()
  .setAccountId(accountId)
  .setKey(newKey.publicKey)
  .freezeWith(client);

// The current key and the new key both sign.
const signed = await (await tx.sign(oldKey)).sign(newKey);
const receipt = await (await signed.execute(client)).getReceipt(client);
console.log(receipt.status.toString()); // SUCCESS

client.close();

Here the account pays its own fee, so the client's operator is the account itself with its current key. Keys come from environment variables so that none is written into the script. Older projects import the same classes from @hashgraph/sdk. Start with the Hedera JavaScript SDK covers the client and receipts.

Result

  • You should now see SUCCESS printed by the script.

Step 5: Confirm the change

Open the account on HashScan, or ask a mirror node for /api/v1/accounts/<your account ID>, and compare its key with your new public key. Mirror nodes can trail consensus by a few seconds.

Then import the new key or recovery phrase into your wallet, and send a small transfer to prove it signs. Only after that, retire the old key. On SentX, disconnect your wallet and connect again with the new key. A key change does not end a SentX sign-in someone else may already have open, so if the old key leaked, also remove the NFT allowances your account gave to SentX. Your listings come down, and you can list again once you are signed in with the new key.

To remove them on SentX, delist your NFTs, which deletes the allowance behind each listing, and clear the HBAR allowances for offers and auctions under Settings › Allowance. A mirror node lists every allowance the account has given at /api/v1/accounts/<your account ID>/allowances/nfts, with /crypto for HBAR and /tokens for tokens. Remove any you did not give with the Hedera SDK, signed with the new key: AccountAllowanceDeleteTransaction for single NFTs, deleteTokenNftAllowanceAllSerials for a whole collection, and an approval of 0 for HBAR or tokens.

Result

  • You should now see your new public key on the account, and a transfer signed with it.

Moving to a threshold key

A threshold key is a list of keys and the number of them that must sign. Set it with the same update. When the new key is a threshold key, at least that many of its keys must sign the update, along with the old key.

import { AccountUpdateTransaction, KeyList, PrivateKey } from '@hiero-ledger/sdk';

// accountId, oldKey and client as in the example above.
const keyA = PrivateKey.fromStringED25519(process.env.KEY_A);
const keyB = PrivateKey.fromStringED25519(process.env.KEY_B);
const keyC = PrivateKey.fromStringED25519(process.env.KEY_C);

// Any two of the three keys can sign for the account.
const twoOfThree = new KeyList([keyA.publicKey, keyB.publicKey, keyC.publicKey], 2);

const tx = new AccountUpdateTransaction()
  .setAccountId(accountId)
  .setKey(twoOfThree)
  .freezeWith(client);

// The old key signs, and so do at least two of the three new keys.
const signed = await (await (await tx.sign(oldKey)).sign(keyA)).sign(keyB);

SentX sign-in works with an account that has one Ed25519 or ECDSA key. An account whose key is a key list or a threshold key cannot sign in to SentX today, so use one for a vault account and keep trading from a single key account.

Safety notes

  • Testnet first. The update cannot be reversed without the new key.
  • Keep the old key until the update is confirmed. If the transaction fails, the old key is still the account key. Retire it only after the new key has signed something.
  • Never paste a key or recovery phrase into a website. Sign in your wallet, or in a script you run yourself.
  • Accounts with an EVM address. An account created from an EVM address, as MetaMask accounts often are, keeps that address for good, and it stays tied to the original ECDSA key. After a rotation it no longer matches the new key, which can break EVM tools and apps that know the account by its address. Hedera's documentation recommends a new ECDSA account, not a rotation, for accounts used with EVM tools. Read Hedera's note.
  • ECDSA keys and MetaMask. Some wallets, HashPack among them, only rekey Ed25519 accounts. If you sign in to SentX with MetaMask, do not rotate that account's key: MetaMask finds your account by its EVM address, which stays tied to the original key, so sign-in stops working. Create a new ECDSA account instead.

Common questions

Does changing the key change my account ID?

No. The account ID is assigned by the network and is not derived from the key, so it stays the same, along with everything the account holds.

Do I need to move my NFTs or relist them?

No. The NFTs stay in the account and the allowances behind your listings stay too. Reconnect your wallet on SentX after the change. If you changed the key because it leaked, see the confirm step about allowances first.

What does it cost?

One network fee for the account update, paid in HBAR at Hedera's published US dollar rate. Your wallet or the receipt shows the exact amount.

Will I need to do this again for post-quantum keys?

Yes, once Hedera adds its post-quantum key type, targeted for 2027, and your wallet supports it. It will be the same kind of update, and the account keeps everything it holds.

If the update fails

  • INVALID_SIGNATURE: a signature is missing. The current key and the new key must both sign, and a threshold key needs at least its threshold.
  • INSUFFICIENT_PAYER_BALANCE: the paying account has too little HBAR for the fee. Get HBAR first.
  • The receipt never arrived: look the transaction up on HashScan before you submit again. Transaction status explains each result.
  • A failed update changes nothing. The old key is still the account key.