Meta Business Manager Security: Roles, 2FA, Recovery

A Meta business portfolio (the account long known as Business Manager) controls Pages, Instagram and WhatsApp accounts, ad accounts and the credit lines that pay for them, so one hijacked full-control user can spend the budget and lock the real owners out. The controls that prevent this are customer-side settings: who holds full control, whether two-factor authentication is required, which system users and tokens exist, and how often someone reads the business history. This guide explains how people, partners and system users get access, how to set a hardening baseline, how to rotate system user tokens without downtime and what to check when a portfolio looks compromised. It is written for marketing operations leads, agency administrators and the security engineers who support them. Menu paths change often in Meta Business Suite, so treat the paths here as a starting point and confirm them in your own portfolio.

This is an independent guide from NHI Mgmt Group, based on Meta's public documentation as of November 2026. It is not sponsored or reviewed by Meta. Product features change, so confirm settings against Meta's current documentation.

Key takeaways

Full control is the crown jewel. Only people with full control can add or remove people, change permissions, change the two-factor requirement and export permissions and business history; Meta's security guidance, as reproduced in ChatArchitect partner documentation, is to keep this group at ten or fewer and to have two active holders.
Require two-factor for everyone. The portfolio setting offers Everyone, Admins only or No one; choose Everyone and push admins towards passkeys or an authenticator app rather than SMS codes.
Session theft beats passwords. Infostealer campaigns aimed at business account holders steal browser cookies and then add an attacker email with admin and finance rights, so endpoint hygiene and fast removal of unknown people matter as much as login strength.
System users are your non-human identities. Use one system user per type of access, keep the single admin system user for administration only and prefer 60-day expiring tokens with refresh and revoke over non-expiring ones.
Business history is your audit log. Download it on a schedule and after any alert, and pair it with the permissions export that shows last activity and two-factor status for every person.

How identity and access work in Meta Business Suite

A business portfolio sits on top of personal identities. People join with their Facebook account (or a managed Meta account if the organisation has moved to them), and the portfolio then grants two layers of access: portfolio permissions and asset permissions. Meta's guidance states that business portfolio permissions override all others.

Identity or access type	What it is	Security meaning
Full control (portfolio)	Top-level access: manage people, permissions, most asset assignments, the two-factor setting, Security Center, permission and history exports	Equivalent to a tenant global admin; the prime takeover target
Basic access (portfolio)	Default level for anyone newly added	Reach comes from the assets assigned, so review asset grants, not just the portfolio level
Asset permissions	Per-asset access to Pages, Instagram accounts, WhatsApp accounts, Commerce accounts, catalogues and ad accounts	Assign only what each job needs; full control of an asset is still powerful
Partners	Another business portfolio (for example an agency) given access to your assets	Their people inherit access you cannot see directly; remove partners separately from people
System users	Non-human users for API integrations, with an admin system user and regular system users	Hold tokens that act without a person or a login prompt
Managed Meta accounts	Organisation-managed accounts administered in Organization Manager	Lets you block invitations to personal Facebook accounts under Security settings

Two practical consequences follow. First, a person's portfolio access is only as safe as their personal account, so the two-factor requirement and passkeys protect the business. Second, invitations go to the email that matches the person's Facebook account, and Meta shows name, work email and assigned assets to full-control holders, which makes the People list the natural place to spot an address that does not belong.

Admin roles and privileged access

Keep full control small and paired

Ten or fewer: according to ChatArchitect partner documentation reproducing Meta Business Help Center text, Meta's Security Center recommends limiting full control to ten or fewer people. In most organisations two to four is enough: a marketing owner, a deputy and an IT or security administrator.
Two active holders: the same partner documentation says Meta recommends two active people with full control so that second admin approval can apply to sensitive actions such as sharing credit lines or changing another full-control user's access. Pending approvals appear under Requests in Settings.
Named work identities: the Security Center flags users with public email domains unrelated to the business. Where the organisation can, move to managed Meta accounts and block invitations to personal Facebook accounts.
Finance access is privileged: anyone who can share credit lines or edit payment settings can turn a takeover into direct financial loss. Review who holds finance permissions as carefully as full control.

Require two-factor authentication

Only full-control holders can change the requirement, under Settings in Meta Business Suite, Business portfolio info, Business options, Two-factor authentication. According to ChatArchitect partner documentation of the Meta setting, the options are Admins only, Everyone and No one. Meta applies the requirement to some older portfolios and to newer ones on request. Choose Everyone. Expect two side effects: users in private browsing or with automatic history clearing are prompted for a code at every login, and third-party tools that manage Pages or ad accounts ask for a login code at sign-in.

Method	Resistance to phishing and replay	Recommended for
Passkey	Highest; bound to the site and device	Every full-control and finance user (Meta's guidance describes passkeys as stronger than SMS codes)
Authenticator app	Good against password reuse, can be phished in real time	All other users, with a backup of the app
SMS code	Weakest; exposed to SIM swap and real-time phishing	Fallback only
Recovery codes	Offline, single use	Saved by every admin in a password manager or sealed store

No form of two-factor stops a stolen session cookie. That is why the controls in the logging and endpoint sections below matter even when every user has a passkey. See the Device-Bound Passkeys guide for choosing passkey types.

Integrations, API tokens and system users

Agencies, ad platforms, CRM connectors and reporting tools usually reach the portfolio through system users and their access tokens. Treat them as you would service accounts in any SaaS tenant. The Social platform app tokens guide covers user and Page tokens across social APIs; this section covers the Meta business-side controls.

System user design

Limits: Meta's documentation allows one admin system user per business by design, and one regular system user at Standard access or ten at Advanced access for Ads Management Standard Access.
One system user per access type: Meta recommends a separate system user for each type of access so that a compromised token has limited scope, for example one for reporting and one for campaign management.
Admin system user for administration only: it can create system users and ad accounts and assign permissions; Meta advises limiting it to administrative tasks, not asset access, and safeguarding its token carefully.
Same business, reviewed app: the app must belong to the same business as the system user, the system user must install the app and grant itself access to assets, and the app needs app review (and business verification where applicable) for the permissions requested.

Token lifetime and rotation

Token	Lifetime per Meta documentation	Control
System user token, expiring	60 days; created with set_token_expires_in_60_days=true	Preferred. Refresh before expiry or the token is forfeited
System user token, non-expiring	Never expires	Only where offline access is needed and leak risk is accepted; inventory and revoke on staff or supplier change
Long-lived user token	About 60 days	Avoid for integrations; tie automations to system users instead
Long-lived Page token	No set expiry; invalidated only under certain conditions	Inventory and revoke when the integration ends
Short-lived user and Page tokens	Hours	Fine for interactive use

Meta documents a zero-downtime rotation: refresh the current expiring token through the oauth/access_token endpoint with grant_type=fb_exchange_token, deploy the new token, then revoke the old one through oauth/revoke. Revocation is immediate and is the documented path for compromised tokens. Some businesses are required to use expiring tokens, and token creation for them fails if the expiry parameter is omitted.

App-side protections

appsecret_proof: an HMAC-SHA256 of the access token keyed with the app secret. It is required when generating system user tokens and makes a stolen token harder to reuse from another system.
Require App Secret: App Settings, Advanced, Security. With it on, calls without appsecret_proof fail, so client calls must go through your backend.
Server IP Allow List and Update Settings IP Allow List: restrict which IP addresses may call the Graph API with the app secret and which may change app settings. Use fixed egress addresses, since a changing residential IP can lock you out.
Login settings: Strict Mode for redirect URIs is required for all apps; also turn on Enforce HTTPS and turn off embedded browser OAuth login and Client OAuth Login where the app does not use them.
Secret storage: keep the app secret and system user tokens server-side in a secrets manager, never in browser code, spreadsheets or agency email threads.

Logging and detection

The portfolio offers three native evidence sources. None of them streams to a SIEM by default, so build a routine around exports.

Source	Where	What to look for
Business history	Download from the People or Business info tab	New people, role changes, new partners, changes to portfolio details or assets, payment changes
Permissions export	People tab in Meta Business Suite Settings (excludes pending invitations)	Last activity, two-factor status, full-control holders, inactive users
Security Center	Available to full-control holders	Open recommendations: inactive users, users without two-factor, public email domains, possible malware, suspicious credit line activity
Ad account and billing alerts	Ad account and payment notifications	Spend spikes, new campaigns in unfamiliar regions, new payment methods

The threat pattern to detect is well documented. WithSecure's research on the DUCKTAIL infostealer describes lures sent through LinkedIn to people with access to Facebook business accounts, theft of browser cookies to reuse authenticated sessions (ATT&CK T1539 Steal Web Session Cookie and T1550.004 Web Session Cookie), and the attacker then adding their own email with admin and finance editor roles (T1098 Account Manipulation). The lure maps to T1566.003 Spearphishing via Service. The WithSecure advice is to review users added to the business account, revoke unknown users with admin or finance roles, end all active sessions and reset credentials. See the Infostealer Logs and Session Token Abuse Guide for the wider session theft picture.

Metrics that show the controls work

Full-control count: holders with full control, target ten or fewer and at least two active.
Two-factor coverage: percentage of people with two-factor on in the permissions export, target 100 per cent; passkey coverage for full-control and finance users tracked separately.
Inactive access: people inactive for 90 days or more still in the portfolio, target zero.
Token hygiene: non-expiring system user tokens in use, with an owner and justification for each, and the age of the oldest token.
Review cadence: days since the last business history review, target under 30.

Hardening baseline

Roll the baseline out in this order so that nothing locks out the legitimate team.

Inventory: export permissions and business history; list every person, partner, system user, app and credit line. Record who owns each.
Protect the admins first: make sure each intended full-control holder has a passkey or authenticator app, saved recovery codes and a current phone number on their Facebook account.
Pilot the requirement: set two-factor to Admins only for one to two weeks, check that agency tools still sign in, then switch to Everyone.
Cut privilege: reduce full control to the agreed holders, move everyone else to basic access with specific asset permissions, and remove people inactive for 90 days.
Clean the edges: remove unused partners, close or remove ad accounts with no ads in a year (they cannot be deleted from the portfolio), and review shared credit lines.
Rebuild integrations: one system user per access type, expiring tokens with a refresh job, Require App Secret and IP allow lists on, secrets in a vault.
Turn on peer approval: set up ad account and domain security so that ads need peer approval where the feature is offered, and verify the domain so only verified domains are shared with partners.
Schedule review: monthly business history and Security Center review; quarterly access recertification with asset owners.

Rollback: if the two-factor requirement blocks a critical user, a full-control holder can step it back to Admins only while that user enrols, rather than to No one. If a token refresh job fails, the old expiring token keeps working until its own 60-day expiry, which gives time to fix the job.

Small business versus agency or enterprise

Small business: two full-control owners, Everyone two-factor with passkeys, no non-expiring tokens, and a monthly look at business history. The Social Media Account Security for Small Businesses Guide covers the personal account side.
Agency or enterprise: managed Meta accounts with personal account invitations blocked, partner access instead of adding agency staff as people, a documented system user register with owners, and second admin approval for credit lines.

Common misconfigurations

Everyone has full control: convenience grants accumulate until a dozen people, including former staff, can add attackers. Limit it and recertify quarterly.
Agency staff added as people: individual agency employees added directly stay after the contract ends. Share assets with the agency as a partner, and remove the partner when the work ends.
Two-factor left at Admins only: any user with asset permissions can be phished into posting or spending. Move to Everyone.
Non-expiring tokens in agency tools: a token that never expires outlives the contract and the person who created it. Use expiring tokens and revoke on offboarding.
Admin system user used for daily API calls: its token can create users and assign permissions. Keep it for administration and use scoped system users for asset access.
Nobody reads business history: attackers add an email, wait, then spend. A monthly review would catch the addition first.

Responding to a hijacked portfolio

Contain from a clean device: a remaining full-control holder removes unknown people and partners, revokes unknown system user tokens through oauth/revoke and removes suspicious credit lines.
Reset the entry point: the affected person ends all active sessions on their Facebook account, changes the password and re-enrols two-factor; treat their device as infected until scanned.
Preserve evidence: download business history and the permissions export before further changes, and keep ad account billing records for disputes.
Report: contact Meta support about unauthorised activity and notify your bank or card issuer about fraudulent ad spend.
Recover and harden: if no legitimate full-control holder remains, follow Meta's business support recovery process; then apply the baseline above.

The Social Media Account Takeover Playbook gives roles and decision points, and the Hacked Social Media or Email Account Recovery Guide covers the personal account recovery that usually comes first.

Framework mapping

Control	NIST SP 800-53 Rev 5	NIST CSF 2.0
People, partner and system user inventory, removal of inactive users	AC-2 Account Management	PR.AA-01
Small full-control group, scoped asset permissions, one system user per access type	AC-6 Least Privilege	PR.AA-05
Two-factor requirement for everyone, passkeys for admins	IA-2 Identification and Authentication	PR.AA-01
Business history and Security Center review	AU-6 Audit Record Review	DE.CM-03
Agency partners and third-party apps	AC-2, AC-6	GV.SC-07

Practitioner checklist

Full control limited to ten or fewer people, with at least two active holders.
Two-factor requirement set to Everyone; passkeys for all full-control and finance users.
Every admin has saved recovery codes and a backed-up authenticator.
Agencies hold access as partners, not as individual people.
One system user per access type; admin system user used only for administration.
System user tokens expire every 60 days with a tested refresh and revoke job.
Require App Secret, Server IP Allow List and Update Settings IP Allow List turned on.
People inactive for 90 days removed; Security Center recommendations cleared.
Business history and permissions export downloaded and reviewed monthly.
Hijack runbook written, with a named second full-control holder and Meta support route.

Meta Business Manager Security: Admin Roles, 2FA and Hijack Recovery