Least-privilege access for small teams: roles, contractors, 2FA and access reviews

Least-privilege access sounds like something for large companies with security departments. In practice it matters most in small teams, where one person's laptop, password or bad afternoon can reach everything. A five-person company where everyone is an admin on every system has no real boundaries. It just has not been tested yet.

At Oryvelon we operate several independent companies with small teams and a mix of employees, founders and contractors. Least privilege and two-factor authentication are group-wide principles. This article explains the practical model we use — roles, contractor accounts, 2FA, quarterly access reviews and offboarding — in a form any small team can adopt without buying anything new.

What least privilege means in a small company

Least privilege is simple to state: every person and every system gets the minimum access needed for the work they are doing now, for as long as they are doing it.

Three parts of that sentence carry the weight.

• Minimum. A designer needs the design files and the staging site, not the payment dashboard. A support agent needs to look up a customer's order, not export the whole customer table.
• Now. Access granted for a project six months ago is not automatically needed today.
• As long as. Temporary work should mean temporary access, with an end date.

Small teams resist this because it adds friction. Someone asks for access, someone else has to grant it, and in the meantime work waits. The trick is to make the right access easy to grant and the wrong access easy to notice, rather than to make everything slow.

Why "everyone is admin" breaks down

It is worth being specific about what goes wrong, because the risks are ordinary rather than dramatic.

Compromised accounts. A phishing email or a reused password turns one person's account into an attacker's account. If that person had access to everything, so does the attacker.

Honest mistakes. Admin rights make it possible to delete the wrong project, change the wrong DNS record or run a script against production instead of staging. Narrower permissions turn many of these mistakes into error messages.

Departures. When someone leaves, the team has to find every system they could touch. With universal admin, that is every system, often including ones nobody remembers setting up.

Data exposure. People who can browse production data will, occasionally, for good reasons: debugging, answering a support question, checking a hunch. Each time, personal data is seen by someone who might not have needed to see it.

Tenant and company boundaries. In a group like ours, one account with access to every company's systems undermines the whole design of shared infrastructure with separate data. The boundary between companies is only as strong as the accounts that can cross it.

Start with roles, not people

The most useful single step is to define roles per company and grant access through them. A role is a named bundle of permissions tied to a kind of work.

For a typical Oryvelon company, a starting set looks like this:

A few rules make roles work:

Few roles, clearly named. Six roles that everyone understands beat twenty that nobody can explain.

Per company. Roles are defined inside each company. Being an engineer on MerchNivo does not grant anything on CastLyra. Where someone genuinely works across companies, they hold separate roles in each, reviewed separately.

Access through roles, not favours. When someone needs something outside their role, either their role changes or they get a time-limited exception that is written down. "I'll just make you admin for now" is how permanent admins are created.

Owners are few. Owner-level access — billing, domain registrars, account recovery, the ability to add other admins — sits with a very small number of people, with the strongest authentication. Losing control of a domain registrar account is one of the worst things that can happen to a small company; we treat it accordingly in Domain, DNS and email security.

Production data is the most sensitive privilege

In most small companies, the most dangerous permission is not "admin" in a dashboard. It is the ability to read production personal data directly: the database console, the raw export, the log viewer with full payloads.

We treat that access as rare and deliberate.

• Engineers work in non-production environments by default, with synthetic data. See Environments and test data.
• Support tools show what support needs. A support view for KeşifAtlası might show the status of a report and the purchase record, without exposing every answer the person gave about their circumstances unless the ticket requires it.
• Break-glass access exists but is visible. When an incident genuinely requires direct access, it is granted to a named person, for a limited time, with a note of why, and the access is logged.
• Stricter companies get stricter rules. For EduRelia, where the data concerns children, direct access to pupil data is even more limited. The reasoning is in Data minimisation for children in edtech.

Contractors: named, scoped, dated

Contractors are normal in small companies and in a group like ours, where specialist work — a design sprint, a migration, a security review — does not justify a full-time hire. Contractor access is also where least privilege most often fails, because the work is urgent and the relationship is temporary.

Our rules for contractor access:

1. Named accounts only. Every contractor has their own account in every system they use. No shared logins, no "use the team account".
2. One company, one job. Access is scoped to the company and project they were engaged for. A contractor building a landing page for Noveniq does not get access to Noveniq's order data, let alone to another company's systems.
3. End date on day one. The access expiry is set when access is granted, matching the engagement. Extending it is a deliberate decision.
4. 2FA required. No exceptions for "it's just for two weeks".
5. No production personal data by default. If the project truly needs it, that need is written down and the access is limited to the minimum.
6. Their own tools stay theirs. Contractors should not copy company data into personal drives, personal AI tools or personal accounts. We say this explicitly in the engagement.
7. A named internal owner. Someone on the team is responsible for each contractor's access and for removing it.

The same logic applies to agencies and service providers. Within the group, WeAreMedia is the services company; when it works for a sister company, it receives the same scoped, named access as any external provider, not a shortcut because it shares an owner.

Two-factor authentication everywhere

Mandatory two-factor authentication is the highest-value security control a small team can adopt. It turns a stolen password from a breach into an inconvenience.

Our practice:

• Required on every system that supports it — email, code hosting, cloud and hosting consoles, domain registrars, payment dashboards, analytics, e-commerce admin, design tools, password managers.
• Authenticator apps or hardware keys over SMS where the system allows. SMS codes are better than nothing but vulnerable to SIM swapping.
• Hardware keys for owner accounts where possible — registrars, primary email, billing.
• Recovery codes stored safely, not in the same place as the password and not in a chat message.
• Systems without 2FA are flagged. If a tool cannot support it, we ask whether we should be using that tool at all, or at least restrict who has an account. This is part of our quarterly tool review.

A shared password manager makes all of this practical. Each company has its own vault or collection, shared only with the people in the relevant role.

Service accounts and API keys are people too

Least privilege is not only about humans. Integrations, scripts, CI pipelines and AI features all hold credentials, and they often have more access than any person on the team.

Apply the same rules:

• Each integration gets its own credential, scoped to what it needs. A script that reads orders should not be able to issue refunds.
• Credentials are per company and per environment, so a leaked staging key does not open production and a MerchNivo key does not open CastLyra.
• Keys have owners and are rotated on a schedule and when people leave.
• Keys live in a secrets manager or environment configuration, never in code, tickets or chat.

We go into detail in Secrets management basics. The same principle drives our AI gateway: it holds separate model provider keys per company and enforces per-company budgets, so no product can spend another product's allowance or see its traffic.

The quarterly access review

Access drifts. People change projects, contractors finish, tools get added in a hurry. A quarterly access review catches the drift before it turns into risk. It fits naturally into the operating cadence we already run for each company.

A practical review for a small company takes an hour or two:

1. List the systems. Start from the company's tool inventory: code hosting, hosting, database, email, domain registrar, payment, analytics, marketing, support, design, AI providers, password manager.
2. Export or view each system's user list. Who has an account, and with what role?
3. Check each account against current reality. Is the person still working on this company? Is their role still right? Is 2FA on?
4. Check service accounts and keys. Does each have an owner? Is it still used? When was it last rotated?
5. Remove or reduce. Anything unexplained is removed. Anything broader than necessary is narrowed.
6. Record the review. A short note: date, reviewer, systems checked, changes made. Future reviews start from it.

The first review is usually uncomfortable — old accounts, forgotten integrations, a former contractor still on the design tool. That is the point. By the third review it becomes routine.

Offboarding on the same day

When someone leaves, or a contractor finishes, access should end the same day. In a small team, offboarding usually fails not because nobody cares but because nobody has a list.

Our offboarding checklist, per company:

• Disable the person's primary identity (email or single sign-on) first, which cuts off many downstream systems.
• Remove their accounts from every system in the tool inventory, including ones outside single sign-on.
• Remove them from the password manager and shared vaults.
• Rotate any shared secrets they could have seen, and any keys they created.
• Transfer ownership of files, repositories, automations and scheduled jobs they owned.
• Revoke personal access tokens and OAuth grants they authorised to third-party apps.
• Check domain registrar, DNS and email settings for any access or forwarding they set up.
• Record the offboarding with the date and the systems covered.

For someone who worked across several Oryvelon companies, the checklist runs once per company. Separate systems mean separate removals — more work, but no single forgotten account can reach everything.

Onboarding: get access right on day one

Most access problems start at onboarding, when a new person needs to be productive quickly and the easiest path is to copy someone else's permissions. Copying permissions copies every exception that person accumulated.

A better routine:

• Start from the role, not a colleague. Assign the role that matches the job and add nothing else.
• Create accounts from the company's identity, so they can be disabled centrally later.
• Turn on 2FA before granting access to anything sensitive.
• Give a short written note of what the person has access to and how to request more. People ask properly when they know how.
• Record the grant in the same place the access review will look.

Twenty minutes of care on the first day saves hours of archaeology at the first review.

AI tools and least privilege

AI tools add a new category of access that many teams have not thought through. An assistant connected to email, a drive, a code host or a database acts with the permissions of the account that connected it. If that account is an admin, the assistant effectively is too.

Our rules are simple. Connect AI tools with the narrowest account and scopes that work. Do not paste production personal data, credentials or customer records into AI tools that are not approved for that company's data. Product AI features go through the company's own configuration in the shared gateway, with that company's keys and limits, rather than through personal accounts. And when someone leaves, their AI tool connections are revoked along with everything else.

A worked example

Imagine CastLyra hires a contractor for six weeks to improve the talent verification flow. Here is how least privilege shapes the engagement.

On day one, the internal owner creates a named account for the contractor on the code host, scoped to the CastLyra repositories involved, and on the staging environment. 2FA is enabled before the first commit. The access expiry is set to the end of week six. The contractor works against synthetic talent profiles in staging; they never see real talent contact details, identity documents or verification results.

In week four, the contractor needs to understand a verification failure that only happens in production. Instead of granting database access, an engineer on the team reproduces the case with synthetic data, or extracts the relevant non-personal facts — error codes, timings — for the contractor.

At the end of week six, the contractor's accounts expire automatically. The internal owner confirms removal, checks that no keys were created under the contractor's name, and notes the offboarding. At the next quarterly review, the contractor does not appear anywhere.

Nothing about this is heavy. It is a few deliberate steps that keep verified talent data where it belongs; see Verification in talent marketplaces for why that data is so sensitive.

Common mistakes

• Shared "team" logins for tools that charge per seat. The savings rarely justify losing accountability.
• Founders as permanent admins everywhere without 2FA hardware keys. The most powerful accounts deserve the strongest protection.
• Personal email addresses as account owners. When that person leaves, the company may lose the ability to recover the account.
• Integrations authorised by individuals and never re-homed. When the person leaves and their account is disabled, the integration breaks — or worse, keeps working under an account nobody controls.
• Access reviews that only check the main systems. The forgotten analytics tool or old staging server is usually where problems hide.
• Granting production access to speed up debugging and never taking it back.

Summary

Least-privilege access for small teams means giving each person and system the minimum access needed for their current work, for only as long as they need it. In practice that comes down to a few roles per company, production personal data treated as a rare and logged privilege, contractors with named, scoped and time-limited accounts, mandatory two-factor authentication everywhere, per-company and per-environment credentials, a quarterly access review and a same-day offboarding checklist. At Oryvelon we run these practices separately in every company, so that access boundaries match data boundaries and no single account can reach the whole group.

Questions and answers

What is least-privilege access?

Least-privilege access is the security principle that every person, service and integration should have only the permissions needed for its current task, and only for as long as needed. It limits the damage from mistakes, compromised accounts and departures.

How often should a small team review access?

A quarterly access review is a practical rhythm for small teams, alongside immediate reviews when someone joins, changes role or leaves. The review checks every system for accounts, roles and keys that are no longer needed.

Should contractors share a login with the team?

No. Every contractor should have their own named account with two-factor authentication, access limited to the project they are working on, and an expiry date. Shared logins make it impossible to know who did what or to remove one person cleanly.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Data, Privacy & Security

NextSecrets management basics: API keys, rotation and keeping credentials out of code →