Securing your account

Your hosting account holds your websites, your mail and your data. This page covers what you can set up to protect it, in the order it is worth doing: a passkey, then recovery codes, then the rest.

Written for: Customer, Reseller, Administrator

Your hosting account holds your websites, your mail and your data. This page covers what you can set up to protect it, in the order it is worth doing: a passkey, then recovery codes, then the rest.

Everything below lives in the panel under Settings → Security.

A passkey: the single best thing you can do

A passkey is a key that lives in your phone, laptop or hardware token. You use it with your fingerprint, your face or your device PIN. There is nothing to remember and nothing to type — which is exactly why it is safe: a fake website cannot talk you out of your passkey, because the key only works on the address it was made for.

Go to Settings → Security → Passkeys.
Click Add passkey and follow what your browser asks.
Give it a name you will recognise ("iPhone", "work laptop").

Three things worth knowing:

A passkey belongs to one address. If you sign in both on panel1.corecp.dev and on your reseller's own address, you register a passkey on each. That is not an omission; it is the property that makes a passkey impossible to phish.
Once you have one here, it is required here. A code from an authenticator app is refused on this address afterwards. On an address where you have no passkey yet, nothing changes.
Register two if you can — your phone and your laptop. Losing one device then stops being an event.

Recovery codes: the safety net

With your first passkey you get ten recovery codes. You see them once. Keep them out of your browser: printed in a drawer, or in your password manager.

Each code works once and stands in for your passkey at sign-in. Lost the sheet, or think somebody has seen it? Ask for a new set under Security — that makes the old sheet worthless immediately.

If you lose your devices and your codes, your hosting provider is the only way back in. See "For administrators" below; that is an operation on the server, not a button on a website.

Two-step verification with an app

If you have no passkey (yet), protect your account with an authenticator app: you scan a QR code and then enter a six-digit code when you sign in. That is clearly better than a password alone, and clearly weaker than a passkey — a code is something you can be talked into giving to the wrong website.

While you have no passkey, the panel shows a standing notice asking you to register one. It disappears by itself the moment you do.

Your password

One password belongs to your email address, not to an account or a hosting provider. If you work with two providers who both run CoreCP, that is the same password — but what you see on each address stays strictly separate.

When you set a new password, the panel checks whether it appears in known breaches. If it does, it is refused; that is not a judgement about how complicated it is, but about whether it is already public.

Active sessions

Security lists where you are signed in. If you do not recognise something — another device, another place — end that session there. The user on that device is signed out immediately.

When your hosting provider looks inside your account

Your provider or reseller can, when support calls for it, sign in as you. That is visible and bounded:

a banner at the top of the screen says who is looking, with one button to end that session;
such a session lasts at most an hour and never extends itself;
there are things it may not do: change your password, your email address, your two-step verification or your passkeys, reveal secrets, touch billing, or give other people access;
everything that happens is written to the log — under your name and under the name of the person who was looking.

This is not something you approve case by case. If you want to know whether it happened, look at your account's activity view.

For administrators

Three more things belong to this subject on the panel itself.

Not everybody may sign in as a customer. It is an explicit right per person, off by default:

ssh root@panel1.corecp.dev
corecp-panel admin impersonation list
corecp-panel admin impersonation allow support@example.com
corecp-panel admin impersonation deny  support@example.com

Heavy operations ask for a fresh key. Fleet rollouts, join tokens, role and administrator changes, API keys and branding require a factor you proved in the last ten minutes. The panel asks by itself; there is nothing to configure.

Break-glass runs on the server, never over the web. If you have locked yourself out with the IP allowlist, or an administrator has lost every factor:

ssh root@panel1.corecp.dev
corecp-panel admin unlock-ip 203.0.113.10/32      # let this address back in
corecp-panel admin disable-allowlist              # turn the list off entirely
corecp-panel admin reset-2fa admin@example.com    # remove every factor this person has

reset-2fa removes the app enrolment, the passkeys, the recovery codes and the sessions. That is deliberately all of it: half a reset is how somebody stays locked out. Each of these writes an audit row marked for paging, so it is never something that happens quietly.

Filtering the audit log, and linking to it

The Audit log page lists every action anybody took in your environment. The selector at the top right filters by outcome: everything, succeeded, denied or failed. Since round 2's final pass that choice also lives in the web address, which is more useful than it sounds:

/audit?result=error — only what went wrong;
/audit?result=denied — only what was refused (somebody tried something they had no right to);
/audit — everything.

You can bookmark such an address or send it to somebody; they see the same selection. The dashboard uses it too: "104 tasks failed across the fleet" now takes you to exactly those rows instead of to the whole log.

The same thing from a terminal:

ssh panel1.corecp.dev 'corecp-panel audit list --result error --limit 20'

When a filter is on, the page says so with a label at the top and a button to take it off. A list quietly showing part of the truth is worse than no filter.

The limit on outgoing mail is part of this

A website with a security hole sends thousands of messages before anybody notices, and what that costs is not the messages — it is the whole server ending up on a blocklist, so that your ordinary mail stops arriving anywhere.

So there is a ceiling: 100 messages an hour per mailbox, 500 per account. Nothing is refused; mail over the limit is held and delivered later, and your mail program retries by itself. Mail your website sends with PHP counts against the same ceiling, because that is exactly the traffic a compromised site produces.

If a mailbox of yours reaches its limit, you get one message about it that day — and that is worth reading, because a mailbox that suddenly wants to send five hundred messages an hour is usually a password somebody else has.