Account security and two-factor

Your Run account is an email address and a password, with an optional authenticator app as a second step at sign-in. All of it is in Settings under Security.

Run writes to the account address whenever the password or the two-factor setting changes, so a change you did not make shows up in your inbox instead of staying quiet.

Your password

The form asks for at least 8 characters. A long phrase from a password manager beats a short clever one, and it should not be a password you use anywhere else.

• Changing it while signed in: Settings, Security, Change password. It opens the password form.
• Forgotten: choose Forgot password? on the sign-in page and enter the address on the account. If an account exists for it, a reset link is sent there, and the link opens the same form.

Run never asks for your password by email, in a support request, or anywhere other than the sign-in form itself.

Turning on two-factor

Run uses a time-based code from an authenticator app (TOTP): the six-digit kind that rolls over every thirty seconds. There is no SMS option.

1. Open Settings, then Security.
2. Choose Set up authenticator.
3. Scan the QR code with your app, or type the secret printed beside it.
4. Type the six-digit code the app shows and choose Verify and turn on.

The section then reads on, and the session you did it in counts as verified straight away.

From then on, signing in is your password followed by the current code. The code step cannot be skipped: until it is entered, the workspace treats the session as not signed in.

Two things worth doing at setup time:

• Run does not issue printed backup codes. If you want a fallback, add the same secret to a second authenticator app while it is on screen, or keep the secret somewhere safe and private.
• Check that your authenticator app is backed up or synced to your account with its maker. Losing the only device that holds the code is the one situation you cannot fix yourself.

Turning it off, and losing the device

Remove on the authenticator row switches two-factor back off. Removing a factor needs a session that has already been verified with a code, so if the button refuses, sign out, sign back in with the code, and try again.

If the device is gone and you cannot produce a code, you cannot remove the factor yourself for the same reason. Write to support@run.audio from the address on the account and ask for the enrolled authenticator to be cleared, then set one up again from scratch. Nothing in your catalog is affected while that is sorted out.

Your sign-in address

The Security section states the address the account signs in with. It is where the reset link goes, and where every notice about the account is sent.

It is read only in the workspace: there is no self-serve email-change flow today, so a two-sided confirmation would be a button that cannot finish the job. To move the account to a different address, write to privacy@run.audio and say what it should become. That is a correction request about your own data, and it is handled as one.

Where you sign in from

While you are signed in, Run records the IP address your session connects from and when it was last seen, and keeps the addresses seen on your account for as long as the account exists. They are part of the copy of your data you can download from Settings under Your data.

It is there for one job: recognising an account being used by someone who should not have it, and recognising an account that was closed for breaking the rules trying to start again. It is never used for advertising, for working out where you live, or for anything outside Run.

• A shared address is ordinary. Offices, campuses, hotels and mobile networks put many people behind one address, and that on its own means nothing is wrong.
• Travelling does not lock you out. There is no per-device approval step to clear. What protects sign-in is your password and your authenticator app.
• A closed account is the exception. If Run closes an account for breaking the rules, the addresses tied to it stay on a denylist after the account is gone. That is set out in Acceptable Use Policy.

What is recorded, why, and the legal basis for it are described in full in Privacy Policy. Questions about it go to privacy@run.audio.

A security notice you did not expect

The notice names the change (password, or two-factor turned on or off) and goes only to the account’s own address. If one arrives and it was not you:

1. Sign in and change your password immediately. If it no longer works, use Forgot password? to take the address back first.
2. Open Settings, Security, and check whether two-factor is on. If it is off, turn it on now. If it is on and the authenticator is not yours, you will not be able to remove it yourself, so say so in the next step.
3. Open a support request under Technical problem and say what the notice said and when it arrived. If you cannot get in at all, write to support@run.audio from the address on the account instead.

If a reset link you did not ask for turns up, nothing has happened yet: the link is useless until it is opened, and it expires on its own. Ignore it, and treat repeated ones as a reason to change the password anyway.

What else protects the account

• Every request the workspace makes is checked against your session on the server, so signing out on a shared machine ends that browser’s access.
• Run staff need two-factor of their own to reach any admin surface, and that gate is enforced twice: once in the application, and again in the database holding your catalog. See Your data: export and deletion for what is kept about you and why.
• Notices about your releases and your requests reach you in two places at once, which is what makes an unexpected one visible. See Notifications and emails.