GoHighLevel Agency Security: 2FA, Roles & Access (2026)

By Dr Priya Jaganathan, GoHighLevel Certified Admin · HL Growth Partner, Australia · Updated 31 August 2026 · 8 min read

Some links below are affiliate links — if you sign up through them, HL Growth Partner may earn a commission at no extra cost to you. It never changes what we recommend. Full disclosure.

GoHighLevel agency security is the line item nobody prices into a retainer, and it is the one that can end an agency in a single afternoon. Your agency login sits above every client sub-account you have ever built — their contact database, their entire SMS and email conversation history, their booked calendars, their connected payment processor.

Most Australian agencies I audit have between four and nine people who can reach all of that, and at least one of them is a contractor who was handed a password over Slack in 2024 and has never been removed. This guide walks through what each role can actually touch, how two-factor authentication works on the platform, how to give a VA access without giving away the agency, where API tokens leak, and what the Privacy Act expects of you if a client database ever walks out the door.

What a GoHighLevel agency login actually unlocks

The agency view is not a dashboard. It is a master key.

From it, a sufficiently privileged user can open any sub-account, export contacts, read conversation threads, edit automations that send on your clients' behalf, and see which payment processors are connected. If you resell, they can also reach the pricing and wallet layer that decides what your clients are charged.

That concentration is the whole security story: one credential, many businesses. A breach of a single client CRM is a bad week. A breach of the agency account is a notification event across your entire book.

Before you touch anything else, get clear on the difference between agency view and sub-account structure, because almost every access mistake I see is someone granting at the wrong altitude.

HighLevel user roles and permissions: who can reach what

HighLevel documents four role types — Agency Admin, Agency User, Account Admin and Account User (HighLevel Support Portal, 2026). The first two live at agency level; the second two are scoped to sub-accounts you assign.

Roles are only half of it. HighLevel also exposes per-user permission toggles, so two people with the same role label can have very different reach depending on what you switched on.

Treat that matrix as the shape of the system, not a promise about your account. HighLevel ships permission changes regularly, so verify each toggle in your own Settings → Team before you rely on it.

Why Agency Admin gets handed out far too freely

Agency Admin is given away because it makes a support ticket disappear in thirty seconds. Someone cannot see a sub-account, you promote them, the problem stops.

The correct default is that exactly two people hold Agency Admin: you, and one trusted operator as recovery. Everyone else starts as an Account User in named sub-accounts and earns more only when a specific task requires it.

If you want the longer version of that argument, I have written it out in detail in how GoHighLevel roles protect client data.

Two-factor authentication: what is enforced and what is not

HighLevel supports two-factor authentication on user logins, configured from the user's own profile settings under Security, and it added authenticator app support so team members can use time-based one-time codes rather than relying only on SMS or email (HighLevel Changelog, 2026).

For SaaS Mode, the platform goes further. HighLevel's support documentation states that 2FA is enabled by default for new SaaS sub-accounts and that a sub-account admin cannot bypass it, with agency admins able to manually verify a sub-account from the Manage Client page (HighLevel Support Portal, 2026).

What I could not verify is a single agency-level switch that forces every existing agency team member to turn 2FA on their own login. Do not assume one exists. Until HighLevel documents it, treat 2FA for your internal team as a policy you enforce manually.

The practical workaround that actually holds:

• Make 2FA a written condition of access in your contractor agreement, not a suggestion.
• Require a screenshot of the enabled 2FA screen before the account is assigned to any sub-account.
• Re-verify every user quarterly on the same day you review roles.
• Set a session timeout under Agency Settings so abandoned sessions do not stay live indefinitely — HighLevel notes the default is Never and that HIPAA-bound agencies are set to one day (HighLevel Changelog, 2026).
• Remove access immediately for anyone who will not comply, rather than negotiating.

VA and contractor access without handing over the agency

The single most common failure I find in Australian agency accounts is a shared login. One email address, one password, three or four people using it, usually offshore.

It fails on every axis at once. You cannot tell who did what, you cannot revoke one person without disrupting everyone, and your audit log becomes meaningless because every action is attributed to the same phantom user.

Every human gets their own login. No exceptions, no shared inbox credentials, no password managers shared across a whole VA team.

The four rules for contractor access

• Own named login tied to an email address you can disable.
• Least privilege — Account User by default, with only the modules the task needs.
• Sub-account scoped, never agency level, unless they are genuinely running your agency operations.
• Time-bound, reviewed on a calendar reminder rather than when you happen to remember.

If you are weighing up delegation models, the trade-offs are worth reading properly — I covered the economics in the hidden cost of VAs versus an implementation partner.

Not on HighLevel yet? Start with a free 30-day trial here — long enough to build everything in this guide before you pay a cent.

Private integration tokens and API keys: where agency access leaks

Human logins get the attention. Tokens are where the quiet breaches happen, because a token has no face, sends no notification, and sits in a Zapier step or an n8n credential store long after the person who created it has gone.

HighLevel's marketplace documentation describes private integration tokens as scoped, static tokens created under Settings → Private Integrations, which do not expire unless you manually revoke or rotate them (HighLevel Marketplace docs, 2026). HighLevel has also deprecated the legacy v1 API in favour of v2 with OAuth 2.0, and states that creating new legacy v1 keys is no longer supported (HighLevel, 2026).

Tokens leak in four predictable places: chat messages, shared documents, screen-share recordings, and automation tools nobody owns. Search your own Slack for the word token before you finish reading this.

Rotate on a schedule and on every departure. The mechanics are in my walkthrough of GoHighLevel private integrations and API access, and HighLevel's own reference is worth bookmarking at the HighLevel private integrations help article.

Offboarding: the checklist that closes the door

Deleting a user is the beginning of offboarding, not the end. The user goes; the tokens, the connected apps and the forwarded notifications stay.

When a whole client leaves rather than a staff member, the process is different again and worth doing properly — see GoHighLevel client offboarding and data export.

Audit logs, wallet and payment exposure

HighLevel provides audit logs at agency level under Settings → Audit Logs, filterable by module, document ID and the user who performed the action (HighLevel Support Portal, 2026). That is genuinely useful for answering who changed this contact.

It is not a full security information log. Do not assume it captures every export, every login attempt, or every integration event — check what your account actually records before you build an incident response plan on top of it.

The wallet is the part agencies forget entirely. If you resell in SaaS Mode, someone with agency access can influence rebilling, usage charges and connected payment configuration, which is a financial exposure sitting beside the data exposure.

The Australian angle: Privacy Act and the NDB scheme

If your agency holds personal information about Australians, the Privacy Act 1988 is the frame. The OAIC notes that businesses with annual turnover of $3 million or less are generally outside the Act, but with significant exceptions — health service providers, and businesses that trade in personal information, among others (OAIC, 2026). Privacy reform is live, so do not treat turnover alone as a permanent shield.

Under the Notifiable Data Breaches scheme, an eligible data breach has three elements: unauthorised access to, unauthorised disclosure of, or loss of personal information; a likelihood of serious harm; and an inability to prevent that harm through remedial action (OAIC, 2026).

Where you suspect an eligible breach, the OAIC states you must take all reasonable steps to complete an assessment within 30 calendar days, and notify affected individuals and the Commissioner as soon as practicable once you form a reasonable belief (OAIC, 2026). Read the scheme directly at the OAIC Notifiable Data Breaches scheme page.

The practical implication for a GoHighLevel agency is simple. If you cannot tell which user touched which client database, you cannot complete that assessment inside 30 days, which is exactly why named logins and role hygiene are a compliance control and not just tidiness.

Agencies operating on both sides of the Tasman have a second regime to think about, which I have covered separately in GoHighLevel CRM and New Zealand privacy compliance.

This article is general information only and is not legal advice. Get advice from a qualified Australian legal practitioner about your specific obligations.

Common mistakes to avoid

• Granting Agency Admin to solve a visibility problem that a sub-account assignment would have solved.
• Sharing one login across a VA team, which destroys attribution in your audit logs.
• Creating private integration tokens with every scope enabled because it was faster than choosing.
• Offboarding a person without revoking the tokens and OAuth connections they created.
• Leaving session timeout at the default forever setting on shared or contractor devices.
• Assuming the platform enforces 2FA for your internal team when that enforcement has not been confirmed.

If you want your team's access locked down before an incident rather than after one, book a strategy call with the HL Growth Partner team.

Book Your Strategy Call →

Or if you just need the software first: grab the 30-day HighLevel trial and book us when you're ready to scale it.

Frequently asked questions

How many people should hold Agency Admin in GoHighLevel?

Two is the practical answer for most agencies: the owner and one trusted operator who can recover the account. Agency Admin reaches every sub-account and the agency settings layer, so each additional holder multiplies your exposure. Everyone else should sit at sub-account level with only the modules their work requires.

Does HighLevel let an agency force two-factor authentication on all team users?

HighLevel supports two-factor authentication per user through profile security settings, and its documentation states 2FA is enabled by default for new SaaS sub-accounts and cannot be bypassed by a sub-account admin. A single agency-wide switch that compels every existing internal team member to enable 2FA is not something I have been able to confirm in HighLevel documentation. Treat internal enforcement as a written policy you verify manually until HighLevel documents otherwise.

Where do I revoke a GoHighLevel private integration token?

Go to Settings and then Private Integrations, select the relevant integration, and revoke or rotate it there. HighLevel documents these tokens as static, meaning they do not expire on their own and remain valid until you act. That is why token revocation belongs on your offboarding checklist rather than your maintenance backlog.

Can a VA see my other clients' data if I scope them correctly?

No, provided you assign them as a sub-account level user restricted to the specific sub-accounts they work in. The risk comes from granting agency level roles for convenience, which exposes the full sub-account list. Always create a named login for each contractor rather than sharing one.

What do GoHighLevel audit logs actually record?

Audit logs are available at agency level under Settings and Audit Logs, and can be filtered by module, document ID and the user who performed the action. They are useful for tracing record changes and attributing activity to a named user. Do not assume they function as a complete security event log, so verify what your own account captures before relying on them in an incident.

What happens under the Notifiable Data Breaches scheme if a client database is exposed?

The OAIC explains that an eligible data breach involves unauthorised access, unauthorised disclosure or loss of personal information that is likely to cause serious harm and cannot be remedied. Where you suspect one, you must take all reasonable steps to assess it within 30 calendar days and then notify affected individuals and the Commissioner as soon as practicable. This is general information, not legal advice.

Is the legacy GoHighLevel API key still safe to use?

HighLevel has deprecated the version 1 API in favour of version 2 with OAuth 2.0 and states that creating new legacy v1 keys is no longer supported. Legacy keys carried broad access from a single static credential, which is the opposite of least privilege. Migrate existing automations to scoped private integration tokens or an OAuth app and remove the old key.

Related Articles on HL Growth Partner

Agency structure and white label

• White label setup guide for HighLevel agencies
• SaaS Mode setup and pricing explained

Billing, wallet and reselling

• Wallet, reselling and usage billing mechanics
• The seven day client onboarding checklist

Team and technical build

• VA versus in-house team for HighLevel implementation
• Inbound and outbound webhook setup