On this page
What access management means
Access management is the discipline of knowing, and controlling, who can reach each of your systems. That includes the obvious ones — servers, website admin panels, databases — and the ones that are easy to forget: the domain registrar, DNS, hosting accounts, code repositories, payment gateway dashboards, email marketing platforms and cloud storage.
In a growing business, access tends to accumulate. A freelance developer is given the hosting password, an agency gets admin rights on the website, a former employee still has an SSH key on the server. None of it is malicious, but every forgotten account is a door that stays open. Our access management service brings that under control, using individual accounts, keys and roles instead of shared passwords.
Who needs it, and the warning signs
Any business that relies on outside developers, agencies or a changing team benefits. Think of a clinic whose website was built by one agency and is now maintained by another, an e-commerce store with several staff in its admin panel, a manufacturer whose ERP vendor has remote access, or a SaaS startup where early engineers had access to everything.
- Passwords are shared over chat or kept in a spreadsheet.
- Everyone uses the same admin login.
- Nobody is sure whether a departed employee or contractor still has access.
- Two-factor authentication is off on hosting, DNS or email accounts.
- Server SSH keys belong to people nobody can identify.
What’s included
- An access inventory — every system, every account, and who it belongs to.
- Individual accounts in place of shared logins wherever the system allows.
- Role-based permissions, so each person has only the access their work requires.
- SSH keys in place of server passwords, with unknown or orphaned keys removed.
- Multi-factor authentication enabled wherever the system supports it, starting with the highest-risk accounts: domain, DNS, hosting, email and code repositories.
- Secrets handling — API keys and database passwords moved out of code repositories and rotated where they have been exposed.
- An offboarding checklist so access is removed completely when someone leaves.
How we deliver it
- Agree scope — which systems are included, and confirm you own them or have the authority to change their access.
- Build the inventory with you, since some accounts only exist in people’s memories.
- Secure the recovery path first — make sure the business, not an individual, controls the owner accounts and recovery email addresses.
- Replace shared access with individual accounts and roles, coordinating with staff and vendors so nobody is unexpectedly locked out.
- Enable MFA and remove stale access, then rotate any credentials that were shared or exposed.
- Hand over the inventory and offboarding checklist, and agree a review interval.
Least privilege without slowing people down
Least privilege means each person and each system has only the access their work needs. In practice, people worry it will create delays — a developer waiting for permission, a marketer unable to update a page. The answer is sensible roles rather than individual exceptions: a content editor role for the website, a deploy-only key for the build pipeline, read-only database access for reporting, and full administrative rights reserved for the few people who genuinely need them.
The same idea applies to software. An application should connect to its database with an account limited to that application’s data, and an API key given to a partner should be scoped to what that partner uses. If one of those credentials leaks, the damage is contained.
What affects timeline and cost
- The number of systems and people involved.
- How many systems support individual accounts and MFA, and how many need workarounds.
- Whether the business already controls its owner accounts, or they first need to be recovered from a former vendor.
- How many credentials need rotating, and how many applications depend on each one.
Common mistakes
- Registering the domain or hosting account in a developer’s personal name.
- Revoking a person’s email account but leaving their server keys and API tokens in place.
- Rotating a database password without updating every application that uses it, causing an outage.
- Enabling MFA on the website but not on the email account that can reset it.
- Reviewing access once and never again.
Frequently asked questions
Do we need to buy a password manager or identity system?
Not necessarily. We can recommend a password manager or single sign-on where it makes sense for your size, but a lot can be achieved with the account and role features your systems already have.
Will staff be locked out during the changes?
We plan changes with you and the people affected, switching each person to their own account before shared access is removed.
Can you remove access for a vendor we no longer work with?
Yes, provided you own the systems. Where the vendor controls an owner account, we help you recover it through the provider’s official process.
Which accounts should get two-factor authentication first?
Start with the accounts that can take over everything else: the domain registrar, DNS, hosting or cloud provider, business email and code repositories. Then move on to website admin panels and payment dashboards.
How often should access be reviewed?
At minimum whenever someone joins or leaves, and on a regular schedule agreed with you, so gradual build-up of permissions is caught.
Talk to us about access management
Who can reach what — with keys, roles and revocation that work when you need them.