Tech

Securing your dev accounts: the basics we put off too often

GitHub, email, SSH, MFA... Securing your dev accounts isn't perfectionist bonus work. It's a foundation. Here's why, and where to start.

Affiliate disclosure: This article contains affiliate links. If you buy through them, I earn a commission at no extra cost to you. I only recommend tools I use or have tested personally. Learn more about my affiliate policy.

When you start coding seriously, you usually think about your portfolio, your projects, GitHub, deployment, design, SEO, visibility. You want to ship, learn fast, show that you're making progress. That's normal.

But there's one topic that many developers, especially at the start, deal with too late: the security of their accounts.

A GitHub account, access to a host, an inbox, a domain name, a Vercel, Netlify, Google, Notion or Stripe account — or even a poorly protected terminal — isn't "just an account." It's already part of your work, your digital identity and sometimes your future income.

Securing your dev accounts is no longer a bonus or perfectionism. It's a baseline. Not because you need to become paranoid. But because you need to be clear-eyed.

The real problem: we think we'll secure it "later"

The classic trap is this one:

"I'm a beginner, I don't have anything important." "My project isn't in production yet." "I'll do that when my business grows."

It's precisely at the start that you need to lay clean foundations.

Because a compromised account isn't only a technical issue. It's also:

  • time lost,
  • damaged credibility,
  • broken deployments,
  • a domain or a repo you no longer control,
  • work emails falling into the wrong hands,
  • and sometimes a real financial loss.

When you build in public, publish on GitHub, and wire several tools together, your exposure surface grows very fast. You open an account here, connect a service there, authorize an integration, paste an API key, log in from several devices — and without discipline, you stack up fragility.

Not all your accounts have the same value, but some are critical

The first mistake is to put all your accounts in the same mental category.

No, your GitHub account, your main email and your domain registrar don't have the same importance as a secondary account opened to test a tool. Some accounts are strategic, because they grant access to the others.

I call them the pivot accounts.

In practice, treat these as ultra-sensitive:

  • your main email address,
  • your GitHub account,
  • your password manager,
  • your deployment and hosting accounts,
  • your domain name,
  • your admin or payment tools,
  • your cloud accounts or technical consoles.

Why? Because if an attacker gets one of these, they can often reset or compromise the rest.

Email, above all, is a central point. If someone gets into your main inbox, they can trigger password resets everywhere. From there, your problem is no longer a single compromised account. It's your whole chain of trust becoming unstable.

A password alone is no longer enough

Let's say it clearly: a good password, on its own, is no longer a sufficient strategy.

Yes, you need long, unique, random passwords, different for each service. That's the baseline. But it's not the end of the subject.

The real level-up is the combination of three things:

  1. a unique, strong password,
  2. a password manager,
  3. two-factor (2FA) or multi-factor (MFA) authentication.

Without a manager, you quickly fall back into the usual bad habits: variations of the same password, scattered notes, fragile routines, fuzzy memory. And without MFA, a stolen or reused password can be enough to open the door.

The manager I use: NordPass — encrypted vault (XChaCha20), strong password generation, autofill on mobile and desktop, and an honest free plan to start. It's from the same company as NordVPN, so the ecosystem stays consistent if you already use one of the two.

Many developers understand security on the code side before taking it seriously on the account side. That's a mistake. Because if your access falls, your code can fall with it.

GitHub: it's not just a place where you push code

For a developer, GitHub is far more than a repository. It's often all at once:

  • a showcase,
  • a work history,
  • a portfolio of proof,
  • a collaborative space,
  • and sometimes a gateway to automated deployments.

A poorly secured GitHub account can therefore have very concrete consequences: deletion or modification of repos, access to secrets, tampering with CI/CD workflows, compromise of automated actions, addition of unauthorized keys or collaborators.

GitHub security starts with simple but non-negotiable moves:

  • enable MFA,
  • regularly review connected devices and sessions,
  • check authorized applications,
  • use clean SSH keys,
  • avoid tokens created "quickly" and then forgotten,
  • review the permissions granted to integrations.

And above all: understand which account you're actually acting with.

It sounds obvious, but in practice, between several GitHub identities, several SSH keys, several machines, several repos, you can quickly create dangerous confusion. The point isn't only to "manage to push." The point is to know precisely who is pushing, with which key, from which environment.

Security isn't just having access. It's keeping control of that access.

SSH: practical, clean — but only if it's well managed

Many developers switch to SSH because it's smoother than HTTPS, and that's often a good idea. But here too, it's not enough to generate a key and forget about it.

An SSH key has to fit into a clear logic:

  • an identifiable key,
  • a coherent configuration,
  • a controlled link to the right account,
  • and ideally a passphrase.

The real danger isn't only the technical side. It's the vagueness.

A machine with several badly named keys. A personal account mixed with a work account. An undocumented SSH alias. A default key pointing to the wrong profile. And, weeks later, no one knows what's actually being used.

When you want to build something solid, you have to get out of invisible tinkering. Even solo. Even on a small project. Even "just to learn."

Security also starts with digital hygiene

We often talk about cybersecurity as a spectacular topic. In reality, a large part of dev account security is mostly about hygiene.

For example:

  • don't store your secrets just anywhere,
  • don't expose a sensitive file in a repo,
  • don't leave tokens lying around in a terminal, a screenshot or a README,
  • don't blindly connect a third-party app to GitHub or Google,
  • don't reuse the same email and password everywhere,
  • don't keep old access "just in case."

Hygiene is also cleanup.

Over time, you accumulate unused accounts, tool trials, old permissions, forgotten integrations. And every forgotten thing is a potential risk. Not necessarily huge. But pointless.

The right reflex isn't to complicate everything. It's to reduce what doesn't need to exist.

Your phone is part of your security

We often forget this: your phone isn't outside your dev environment. It's part of it.

Today it's used to receive MFA codes, approve logins, access GitHub, read security emails, manage passwords, approve connections, sometimes even administer a project on the go.

In other words: if your phone is poorly protected, part of your security is too.

Concretely, that means:

  • serious device lock,
  • updates installed,
  • biometric authentication or a strong code,
  • caution on public networks,
  • particular attention to sensitive apps.

Mobile isn't a secondary accessory. It's often a direct extension of your digital identity.

Security is also a matter of credibility

When you build an online presence — blog, GitHub, portfolio, freelance work, an app in the making — security also becomes a matter of credibility.

What message do you send if you talk about tools, business, building projects, but your own accounts are fragile?

I'm not talking about being an offensive-security expert. I'm talking about being consistent.

A credible developer isn't just someone who can code a clean interface. It's someone who understands that their personal infrastructure also deserves protection. Especially if they want to build for the long term.

Because at heart, securing your dev accounts is protecting your work, your time, your reputation, your progress, and your ability to keep going with peace of mind.

Where to start, concretely?

The most important thing is not to turn this into a mental mountain. You don't need to redo everything in one day. But you do need a simple, serious plan.

1. Secure your main email

Unique password, MFA enabled, review of sessions and recovery options.

2. Secure GitHub

MFA, audit of devices, SSH keys, authorized applications and tokens.

3. Put your identities in order

Which account for which use? Which key for which account? Which device for which context?

4. Use a password manager

Not tomorrow. Now. A password you can memorize is no longer a good password in 2026 — you need a vault that generates and stores unique secrets for each service.

My pick: NordPass. Free plan good enough to start, sync across devices on the paid plans, and import from another manager in a few clicks if you migrate.

5. Do a permissions cleanup

Remove unnecessary access, forgotten integrations, test accounts that accidentally became permanent.

6. Check what you expose publicly

Repo, README, screenshots, environment variables, local config, command history.

7. Document your setup, minimally

Not necessarily a novel. But enough not to lose yourself in three months.

Documentation isn't only a team reflex. It's also a form of self-protection.

What I take away today

The further I go, the more I find that dev account security resembles a lot of important things in technical work: it's not spectacular, it's not always visible from the outside, but it's what prevents costly problems later.

You don't need to be a big company to have good practices. You don't need to wait until you've "made it" to protect what you're building. And you don't need to be a cybersecurity expert to treat your access seriously.

Securing your dev accounts isn't a technical detail.

It's a way of saying: what I'm building matters, so I protect it.

The right tool to start now

If you don't have a password manager yet, that's the #1 step that really changes the security level of your dev accounts. NordPass ticks the right boxes: serious encryption, clean ergonomics, a usable free plan.

Try NordPass →

Affiliate link — see my affiliate policy.

You'll find more practical guides in the Tech section.