Profile: IT professional and sysadmin
This is a context profile for people with privileged access. You manage other people's systems and are therefore targeted for the access you hold, not only your own data.
Profile: IT professional and sysadmin
Who this guide is for
This profile is for sysadmins, DevOps engineers, developers, IT managers, and anyone with privileged access to systems, infrastructure, credentials, or other people’s data.
This profile is for sysadmins, DevOps engineers, developers, IT managers, and anyone with privileged access to other people’s systems.
The fundamental difference from other profiles: you’re not an endpoint, you’re a link in a chain. Attackers aren’t primarily interested in your personal data — they want the access you have to systems, infrastructure, and other people’s data.
That makes your personal security a professional responsibility.
Use this as an additive profile. Choose your base profile first, then layer your IT responsibility and privileged access on top of it.
The main question here is not which setup sounds most hardcore. The main question is: which measures actually reduce the risk of your access being abused, and which are technically impressive but hard to maintain?
When this is overkill
If you do not hold privileged access, production credentials, or responsibility for other people’s systems, you probably do not need the IT-professional layer. This profile matters when your compromise would become someone else’s compromise too.
Threat analysis
Supply chain attacks A compromised sysadmin can provide access to hundreds of systems. Attackers invest more in targeting IT professionals than in directly attacking systems — it’s more efficient.
Social engineering is more sophisticated Attackers know you’re technical. They impersonate vendors, colleagues from IT teams at other organisations, or suppliers. The phishing emails targeting you aren’t the blunt “your package wasn’t delivered” variety — they mimic Terraform Cloud alerts, GitHub security notifications, or tools you specifically use.
Privilege creep Sysadmins receive rights “just for this project” that are never revoked. After a year you have admin access to dozens of systems you can’t remember the purpose of. Every active credential is an attack surface.
Home network as an attack path If you have SSH access to production environments from home, your home network is part of your employer’s attack surface. A compromised home network is a lateral movement path to the infrastructure you manage.
Malicious packages and extensions A specific risk for developers: typosquatting in npm, PyPI and other package registries. Attackers publish packages with names resembling popular libraries (reqeusts, colourama, python3-dateutil). They contain code that steals credentials, exfiltrates SSH keys, or installs backdoors. Malicious VS Code extensions have also been found in the official marketplace multiple times. You install what looks like a legitimate tool — but it’s a beachhead.
What you gain, and what it costs
If you apply this profile seriously, you typically gain:
- less chance that your account or home setup becomes the entry point into other people’s systems
- clearer boundaries between daily workflow and privileged access
- faster revocation and recovery if a device, key or token is suspect
- less silent risk accumulation from privilege creep and forgotten access
But it costs something:
- more operational discipline around keys, sessions, secrets and access
- sometimes extra hardware, separate accounts, or a dedicated workstation
- less convenience because “quickly going admin” is precisely the wrong pattern here
For this profile that is usually a reasonable trade. Your comfort is less important than limiting the blast radius when you become the weak link.
Checklist
Credentials and access
- Unique passwords everywhere — a shared password between personal and work accounts is a direct attack vector
- Hardware 2FA (hardware security key guide) for all critical systems — phishing-resistant by design
- Manage SSH keys: know which keys are active, always use a passphrase, rotate regularly
- Disable SSH agent forwarding unless absolutely necessary (
ForwardAgent noin ~/.ssh/config) — if an intermediate host is compromised, an attacker can use your forwarded agent to reach every system your key has access to - API tokens and secrets: store in a secret manager, never in .env files in repos
- Cloud credentials are the most dangerous category: an AWS/GCP/Azure key with broad permissions gives access to an entire organisation’s infrastructure. Use IAM roles instead of long-lived keys where possible, and scope every key to minimal permissions
- Actively remove access when a project ends — don’t wait for someone else to do it
Separation of work and personal
- Use a separate device for work admin tasks, or at minimum a separate browser profile with separate sessions
- Don’t browse personal content in the same session as work infrastructure management
- Personal password manager not shared with work credentials — if your personal device is compromised, it shouldn’t cascade to work
For many IT professionals this is the first real win:
- separate admin account
- separate browser or profile session
- hardware 2FA on critical accounts
Only after that does a PAW or home VLAN segmentation become the logical next layer.
Home network
- VLAN segmentation at home: IoT devices (smart TV, cameras, thermostat) on a separate segment from work traffic — and your work laptop on its own WORK-VLAN so personal devices have no path to your SSH sessions and VPN tunnels into production (see the WORK-VLAN scenario in the OPNsense guide)
- Router firmware up to date — you know how to do this, so no excuse
- DNS filtering on home network (privacy DNS guide, AdGuard Home, Pi-hole) — also blocks malware domains
- If you VPN into work infrastructure: the machine you do it from must be clean
Code, packages and repositories
- Scan repos for hardcoded secrets before pushing (truffleHog, git-secrets, GitHub secret scanning)
- Signed commits — not just for integrity, also for non-repudiation
- Dependency audits — you’re responsible for what you import
- Verify package names carefully when installing, especially in automated pipelines
- Pin dependencies to specific versions and use lockfiles — prevents a malicious update from coming in automatically
- Vet VS Code extensions: install only from verified publishers with an established track record
Incident response for yourself
- Know how to quickly revoke credentials if you lose a device
- Have a plan for if you get compromised: who do you call, what do you revoke, in what order
- Document your own accesses — you should be able to list right now which systems you have admin rights to
The principle of least privilege — for yourself too
The tendency to give yourself full access “because it’s easier” is understandable. But it’s also a risk. If your account is compromised, your own privilege level determines how much damage an attacker can do.
- Use root or admin rights only when genuinely necessary — then close the session
- Separate admin accounts for management tasks, daily account for everything else
- Least privilege applies to yourself as strictly as to users you manage
- Consider a Privileged Access Workstation (PAW): a separate, hardened device used exclusively for admin tasks. Not used for email, browsing, or personal use. Dramatically reduces attack surface.
Don’t treat a PAW as standard advice for every developer with a homelab. It becomes relevant when you genuinely have broad privileged access, manage production environments, or work with sensitive client infrastructure.
NIS2 and Dutch context
The NIS2 directive had an EU transposition deadline of October 2024 and requires essential and important entities to demonstrate security measures. If you work for an organisation that falls under NIS2, you carry direct operational responsibility for compliance. In the Netherlands, the directive has not yet been implemented in national law; the Cyberbeveiligingswet is expected in Q2 2026. The obligations are therefore not yet formally enforceable in the Netherlands, but preparing early is still worth it.
The Dutch NCSC publishes threat analyses and advisories specific to Dutch sectors — useful to follow if you work in critical infrastructure.
Tools
| Purpose | Tool | Note |
|---|---|---|
| Hardware 2FA | Hardware security key guide | For critical systems and SSH |
| Secret management | HashiCorp Vault / 1Password Secrets | Not in .env in repos |
| DNS filtering at home | Privacy DNS guide / AdGuard Home / Pi-hole | Also blocks malware domains |
| Secrets scanning | truffleHog / git-secrets | Pre-push hooks |
| Network segmentation at home | Network segmentation: VLANs at home / OPNsense | VLAN for work/personal/IoT |
| Secure communication | Signal setup guide | For incident response with colleagues |
| Package scanning | npm audit / pip-audit / Snyk | Dependency vulnerabilities |
Don’t treat this table as a mandatory full package. For most readers in this profile, hardware 2FA, clear account separation and secret discipline matter more than rebuilding every part of your home network immediately.
Next step
Start here
- Hardware security key guide — when, which accounts, and how to roll it out without locking yourself out
- YubiKey vs Nitrokey review — for the product decision once you know you want a key
- Network segmentation: VLANs at home — if your home network is genuinely part of your work access
- OPNsense VLAN segmentation — advanced network segmentation
- Tailscale mesh VPN guide — reach home services without opening ports
Also relevant
- Profile: high risk — for the highest threat levels
- Profile: student or employee — if account and device separation is your first real problem, not infrastructure management
Reviews and further reading
- YubiKey vs Nitrokey review — hardware authentication
- AdGuard Home review — DNS filtering at home
- GL.iNet Beryl AX review — for home network segmentation