Securing the Accounts That Own Your FiveM Server: Cfx.re, Discord, the Host Panel and Everything With a Login

Securing the Accounts That Own Your FiveM Server: Cfx.re, Discord, the Host Panel and Everything With a Login

Every guide about FiveM account security starts inside the game. Anticheat, event validation, resource scanning, all of it useful. Meanwhile the actual disaster scenario involves nobody touching the game at all: someone gets into a Gmail account from 2016, resets a password, and by lunchtime owns your Discord, your domain and the keymaster licence your server runs on. No exploit, no cheat, no clever Lua.

FiveM account security is the boring half of running a server and it is the half where the losses are permanent. A wiped database restores from backup. A stolen Discord with fifteen thousand members does not. This is the list of accounts that genuinely own your server, what happens when each one is taken, and the small number of things that actually make a difference.

Draw the ownership map first

Sit down and write out every account that could shut your server down or take it away from you. Most owners have never done this and are surprised by how long the list is:

• The email address that everything else recovers to. This is the root of the whole tree and it is usually the account with the oldest password.
• Your Cfx.re account and the keymaster licence attached to it. Lose this and your server keys go with it.
• The Discord account that owns the community server, plus whatever bot tokens are running in it.
• The host: a game panel, a VPS provider, or both. Root on the box beats everything else on this list.
• The domain registrar and whatever sits in front of it for DNS. Control of DNS is control of your website, your connect link and often your email.
• The Tebex store account and the payment details behind it.
• Whatever holds your source and backups: a Git host, cloud storage, a NAS at somebody’s house.

Write down, next to each, who has access today. Not who should. Who does. This is where most people find the developer who left in April and still has panel credentials.

The email account is the whole game

Every other account on that list has a “forgot password” link, and nearly all of them point at one mailbox. If that mailbox has a fifteen character password from a breach in 2019 and no second factor, none of the rest matters.

Give the root email its own treatment: a long unique password, hardware key or authenticator app rather than SMS, recovery codes printed and stored somewhere physical, and no forwarding rules you did not create. Check the forwarding rules specifically, because a quiet forward is the most common thing an attacker leaves behind, and it survives the password change you make in a panic afterwards.

For anything with money attached, and for the Cfx.re account, consider a separate mailbox that is used for nothing else. Boring, and it means a compromised personal email does not automatically hand over the server.

Cfx.re, keymaster and the licence you cannot re-issue casually

Your server key lives in keymaster under a Cfx.re account. Whoever holds that account can create keys, revoke keys, and see what you are running. Treat it as production infrastructure rather than as a forum login, because that is what it is.

Two habits worth forming. Keep the number of people with access to it at one or two, and make sure at least one of them is you personally rather than a shared “admin” identity. And keep a record of which key belongs to which server, because the day you need to revoke one in a hurry is not the day to find out you have four and no notes.

Since txAdmin authenticates through Cfx.re by default, this account and your admin panel are frequently the same trust boundary. If the person holding the Cfx.re account is compromised, assume the panel is too.

Discord: the asset you cannot restore from a backup

The Discord is the community. Members, history, roles, relationships. If someone takes ownership of it, there is no restore point, and Discord’s recovery process for a hijacked server owned by a compromised account is slow and not guaranteed.

The specific threat here is not password guessing, it is token theft. Info-stealing malware, usually delivered as a “check out my new script” download or a cracked tool, grabs the session token straight out of the client and skips your password and your 2FA entirely. That is why the advice on this one is different: turn on 2FA, yes, but the thing that actually protects you is not running unknown executables on the machine you administer from. Test downloads on a machine that does not hold your community.

Practical steps that cost nothing: turn on the server setting requiring 2FA for moderation actions, keep ownership on an account that exists for that purpose rather than on the personal account of whoever founded it in 2021, limit how many people hold administrator permission, and audit bot permissions. A bot with administrator that you added for a giveaway two years ago is a full account compromise waiting for its developer to have a bad day.

Host, root and the panel

If someone has root on the box, they have everything: your database, your keys, your source, your players’ data. Treat SSH properly. Key authentication rather than passwords, no root login over SSH, and access restricted to a small set of addresses or through a private network rather than open to the whole internet.

On the panel side, give every admin their own login. Shared credentials mean that when somebody leaves, you either change a password everyone uses or you leave them with access, and in practice most teams do the second one. Individual accounts also mean the audit log is worth reading, which matters enormously when something goes wrong and the question is not “was it malicious” but “who ran that”.

The permissions question here is the same one you have already answered inside the game. If you have thought carefully about who on your staff team can do what, and who watches them, apply the same reasoning to the infrastructure, because that is where the damage is irreversible rather than merely annoying.

DNS, the domain, and the quiet takeover

Domain hijacking is undramatic and effective. Nobody notices for a while, because the server still runs. The website points somewhere else, or the email starts going somewhere else, and the first sign is often a player asking why your store is asking for their card details on a page that looks slightly wrong.

Lock the domain at the registrar, put 2FA on the registrar account, and keep the registrar contact email in your controlled mailbox rather than one belonging to whoever set it up. Watch the expiry date. More FiveM domains have been lost to a card expiring than to any attacker.

Staff turnover is a security event

People leave. Sometimes politely. The offboarding checklist is short and almost nobody has one:

1. Remove the panel account, do not just change the role.
2. Remove their SSH key from the box and check for any others you do not recognise.
3. Rotate any shared secret they knew: database passwords, webhook URLs, API tokens, bot tokens.
4. Remove their Discord permissions and check they do not own any bots or integrations in the server.
5. Check for scheduled tasks, cron jobs and resources they added, especially anything that phones out.

That last one connects to the other side of this problem. Code you did not write, running on your box, with your database credentials, is an access route that no password policy touches. Reading an unfamiliar resource before you trust it is its own discipline, and running an audit pass over a purchased script should be part of onboarding a new resource in the same way removing a key is part of offboarding a person.

Noticing, and having a plan for the bad morning

Detection here is mostly about noticing logins. Turn on login alerts everywhere they exist, review the active sessions list on your email, Discord and registrar occasionally, and put alerts on the things that should never happen: a new panel admin, a DNS record change, a new Cfx.re key. If you already have monitoring on the server itself, this is the same instinct pointed at the accounts instead of the process list.

Write the incident plan while nothing is on fire. One page: who to contact at the host, where the recovery codes physically are, which passwords rotate first and in what order, and how you tell the community something has happened. The order matters more than people think. Root email first, then anything that resets through it, then the rest. Rotating your Discord password while the attacker still controls your inbox is a very fast round trip.

If ownership of the server ever changes hands, all of this becomes the handover checklist, which is why the same list turns up when people talk about selling or handing over a server. Knowing which accounts constitute the server is the same knowledge whether you are protecting it or transferring it.

The short version

Map the accounts that own your server, harden the email everything recovers to, give Cfx.re and Discord the treatment you would give production infrastructure, keep individual logins for staff, lock the domain, and write an offboarding checklist that includes rotating secrets. None of it is interesting. All of it beats explaining to fifteen thousand members why the Discord now belongs to somebody in another country.