Multi-Accounting for IT Outsourcing: Client SaaS Admin Access

GetAntik editorial team · October 7, 2026 · 9 min read

MSPs managing dozens of client tenants need isolated browser profiles for Microsoft 365, AWS, and hosting panels. Here's how to set it up without chaos.

A company servicing 30–50 clients as an IT outsourcer eventually runs into the same wall: every client has their own Google Workspace, their own Microsoft 365, their own AWS console or hosting panel — and all of it has to be administered from the same browser by the same technician. Logging in and out ten times a day isn't realistic, and giving every technician a separate laptop per client isn't either. In practice, teams either live in a mess of tabs and constant logout/login cycles, or they switch to isolated browser profiles per client. The second path works noticeably better, but it has details worth understanding upfront.

Why one browser for all clients is more than just inconvenient

The problem isn't only the constant switching between accounts. SaaS admin consoles have quirks that make mixing client sessions in a single browser profile genuinely risky:

• Autofill and suggestion history. The browser remembers emails, addresses, and search queries across consoles. Working with a dozen clients, autofill starts mixing up domains, passwords, and settings — a technician pastes the wrong data into the wrong field on autopilot.
• Cookies and local storage overlap. Some consoles — especially those built on shared SSO providers like Okta or Azure AD — store session tokens in a way that opening a second tab for another client resets the first session or offers to "continue as" the wrong account.
• Conditional access reacts to device and IP. Microsoft 365 and Google Workspace can trigger security alerts and even block sign-in when a device, browser, or IP geolocation looks "atypical" for an account. If a technician logs into ten different tenants in a row from the same browser fingerprint and the same IP, some clients' Conditional Access policies will flag it as suspicious and demand re-verification or block the session outright.
• Extensions and local settings are shared across everyone. A plugin installed for one client (say, a custom SSO connector) can conflict with another client's setup.

The result: technicians either keep dozens of incognito tabs open and waste time re-authenticating, or they create separate local Windows accounts per client — which is already closer to managing virtual machines than to fast support work.

What an isolated profile per client actually changes

An antidetect browser solves this literally: one profile equals one client, with its own set of cookies, history, autofill, extensions, and a managed fingerprint (OS, browser version, screen, timezone, and language derived from the exit IP). For an MSP this isn't about getting past ad-platform detection — it's about clean technical isolation and making sure sign-ins look stable and predictable to the client's systems.

The practical payoff breaks down into a few points:

1. A stable fingerprint means fewer repeated MFA prompts. If client A's profile always signs in with the same browser parameters and, where needed, a proxied IP from the client's region, conditional access recognizes a familiar device and skips extra verification. For clients with strict security policies — finance, healthcare, government — this is especially noticeable: without isolation, technicians spend 5–10 minutes re-verifying identity on every single login.

2. No risk of acting in the wrong tenant by accident. Most MSPs will tell you their costliest incidents weren't breaches — they were an admin deleting a user or changing a DNS record for the wrong client because the tabs all looked the same. A separate profile with the client's name clearly labeled in the profile list cuts this risk close to zero: switching becomes a deliberate action, not a jump between tabs in one window.

3. A 2FA key vault per client. Most consoles — Microsoft 365, Google Admin, AWS root, hosting panels — require two-factor authentication. Keeping all those codes in one authenticator app on a technician's phone is a bad habit: when that employee leaves, the company either loses access to someone else's 2FA or has to manually reissue it for every affected client. In GetAntik, the 2FA key lives inside the profile itself — it moves along with the profile if access is handed off to another employee.

4. A client-region proxy only where it's actually needed. This is the one place not to overdo it. If a client doesn't enforce strict location-based access policies, a proxy isn't necessary — a profile with the correct timezone and system language is enough. But if a client has rules like "sign-in only from the country of company registration" or an "impossible travel" alert (login from one country an hour after login from another), it's worth keeping a proxy matched to that geography for that specific profile, so you're not generating tickets for their security team.

Which consoles most often require isolation

Not every console needs a dedicated proxy or strict fingerprint management — but isolating cookies, autofill, and 2FA is useful almost everywhere.

How to organize this inside the team

For an MSP with 5–15 technicians, the usual setup looks like this:

1. One profile per client, not per service. If a client uses Microsoft 365, AWS, and hosting, it's generally more logical to keep them in a single profile (one tab per console) rather than creating three profiles for one client. The exception is when different technicians need access to different consoles — say, DevOps handles AWS while the service desk handles Microsoft 365. In that case, split profiles by "client + area of responsibility."
2. Roles and limits matched to specialization. Senior engineers get access to AWS root consoles and Microsoft admin panels; first-line staff get access only to ticketing systems and basic dashboards. In GetAntik this is configured through team roles and per-member limits — more detail on setting that up is in the piece on role assignment and profile handoff.
3. Handing off a profile when the responsible person changes. A client account transfers from one technician to another together with the profile — settings, cookies, the saved 2FA key, and the activity history. This removes the classic MSP problem where a departing employee is literally the last person who remembers passwords to half the client panels.

1. Supervising junior staff. Live view and remote control of a teammate's browser aren't just oversight tools — they're a genuine training mechanism: a senior engineer can join a new hire's session during their first pass through a client console, offer guidance, and even step in, without asking anyone to share their screen through a third-party service.
2. An activity log for compliance. If the company operates under SOC 2 or similar requirements, a per-profile activity log is a ready-made audit artifact: who logged into which client system, and when.

Where this overlaps with other MSP tasks — and where it doesn't

A similar isolation logic has already been covered for accountants and lawyers, who also juggle dozens of client portals and strict data-separation requirements. If your company combines accounting and IT functions — common among small full-service outsourcers — it's worth reading the piece on accountants and lawyers working with client portals; the profile-separation principles there are nearly identical.

The difference for IT support is the need to automate routine operations — bulk user creation, policy configuration, license status checks across dozens of tenants. If the team already scripts these tasks with Puppeteer or Playwright, profiles can be connected directly via the local API — covered in detail in the article on automating profiles with Puppeteer and Playwright. That saves hours when onboarding new users for a client with a standard configuration.

Common mistakes

One shared profile "for all the small clients." The savings look reasonable right up until that profile has ten active MFA sessions at once and token conflicts start. Splitting into separate profiles is cheaper than an hour of downtime caused by a locked-out client system.

No handoff process when someone leaves. If 2FA and passwords live on a personal phone and in someone's head rather than in a profile, replacing a technician turns into a multi-day project involving the client to reissue access. For a detailed action plan, see the piece on closing off access without losing client accounts.

Running a proxy where it isn't needed. Not every client enforces geo-restrictions, and paying for a proxy on every profile is unnecessary overhead. A proxy only makes sense where a client has genuine location-based policies in place or a history of security alerts tied to login geography.

Ignoring how profile data is encrypted. Client 2FA keys and session cookies are sensitive data — a leak from a technician's device or from the antidetect browser provider's server would be a serious incident for an MSP. In GetAntik, profile data is encrypted on the device with the account password, and the server itself physically cannot read it — which removes part of this risk when evaluating a tool. More on the encryption model is in the article on profile security and the 2FA vault.

Where to start

For a team of 5–10 technicians serving 20–30 clients, a reasonable starting point is a plan with enough profile headroom for current clients plus 20–30% for growth — new contracts, test environments. Check current limits and pricing on the pricing page, and download the app for macOS or Windows from the download page. If the company already has a role split (service desk, engineers, DevOps), it's worth setting up team permission management right away rather than bolting it on later once you're past 50 profiles.

FAQ

Does this violate Microsoft 365 or Google Workspace terms of use? No, as long as you're accessing client accounts with their knowledge and under a service agreement. Isolating sessions into separate profiles is a matter of how you organize work, not a way of getting around platform rules. Platforms actually benefit from sign-ins looking stable and not triggering false security alerts.

Do I need a proxy for every client by default? No. A proxy is needed where a client has enabled conditional access policies based on geolocation or has had incidents involving "unusual location" alerts. For everyone else, isolated cookies, autofill, and a consistent profile fingerprint are enough.

What if a client requires sign-in only from a specific static IP? Attach the profile to a proxy with that static IP through the proxy manager and keep that profile restricted to a limited set of technicians — this is a case where role-based limits matter most, so you're not creating unnecessary access points.

What about clients who have multiple in-house admins making changes alongside us? Profile isolation only solves the problem on your side — it doesn't replace the client's own role model inside their console. Use separate administrative accounts issued specifically to your company, not one shared login for everyone.

multi-accountingantidetect browsermspsaas admin accessteam security