Requiring Two-Step Login Across a Business Container: Policy and Rollout

Editorial team Spend Ledger

Why a shared business environment needs a clear rule

A business-level container can hold access to advertising accounts, payment settings, audiences, creative assets and other work materials. A person who signs in through a compromised account may therefore expose more than their own work. They may be able to change shared settings, disrupt campaigns or affect other people’s access.

Requiring two-step login for everyone with access adds a checkpoint beyond a password. It does not remove every security risk, and it cannot replace careful account management. It does make it harder for someone with a password alone to enter an account, depending on the platform’s authentication process and the method selected.

The requirement should apply to every person who can access the container, not only those who create campaigns or manage billing. People with limited or occasional roles can still provide a route into shared assets. At the same time, access should be granted only when it is needed for work. Two-step login is a safeguard, not a reason to keep unnecessary access active.

An organisation should treat the container and its accounts as work tools, whether they were set up internally or obtained through an authorised business arrangement. Purchasing or receiving access does not change the platform’s rules. The organisation remains responsible for using the assets lawfully, maintaining accurate account information and following the platform’s current security requirements.

Define the requirement before announcing it

A short written policy helps prevent inconsistent expectations. It should say who is covered, what must be enabled, how people can get help and what happens if someone cannot complete the setup. Use plain language and avoid implying that a particular authentication method is available to everyone; options vary by platform and account.

The policy should also establish ownership. Name an internal role or team that maintains the access list, communicates changes and handles support requests. This does not mean collecting passwords or authentication codes. People should retain control of their own sign-in credentials, while designated administrators manage access through the platform’s approved functions.

Before setting a rollout date, review the platform’s current help and policy pages. Confirm how its two-step login requirement works for business access, whether it applies to all roles, and what recovery options it supports. Platform features and rules can change. If a setting or requirement is unclear, seek clarification through the platform’s official support channels rather than relying on assumptions.

Keep the policy focused. It can cover the security purpose, required action, acceptable recovery preparation and a route for reporting problems. Avoid adding informal exceptions that could become a way around the requirement. If a person cannot comply, pause their access where appropriate and resolve the issue through official processes.

Map access and prepare the rollout

A rollout is easier to manage when the organisation knows who has access and why. Review the people and roles listed in the business container, then check whether each access assignment is still needed. Remove access through the platform’s normal administrative process when a person no longer requires it. Do not share one person’s login to preserve access for a team.

Identify groups that may need additional support, such as staff who use managed devices, people who travel for work or those whose role depends on uninterrupted access. This is not a reason to exempt them. It is a prompt to plan for setup and recovery before the requirement takes effect.

Choose a rollout sequence that fits the organisation’s operations. A team might begin by communicating the policy, then allow time for people to prepare an approved authentication method, followed by a check of completion. For a larger or more complex team, administrators may need to coordinate with internal security or support staff. The schedule should be realistic, but its current dates and any platform-specific deadlines should be confirmed against official platform information.

Before communication goes out, test the instructions using the platform’s current interface and help material. Do not invent menu names or promise that the same steps will appear for every person. Provide a general route to the relevant security settings and direct people to official guidance for exact steps.

Announce the change in practical terms

The announcement should explain what is changing, why it matters and what each person needs to do. Emphasise that the policy protects shared business assets and reduces reliance on passwords alone. Avoid presenting it as a performance measure or implying that someone who needs assistance is at fault.

Include the following information in the announcement:

• Who must enable two-step login, including people with occasional or limited access.
• Where to find the platform’s official setup and recovery guidance.
• Which authentication and backup options the organisation accepts, subject to platform support.
• How to contact the designated internal support role if setup fails or a device is lost.
• What will happen to access when someone remains unable to meet the requirement.

Give people a clear way to ask questions privately. They may need help without disclosing sensitive details in a group channel. Support staff should never ask for passwords, one-time codes, recovery codes or a complete set of authentication information. If a request appears to come from a manager or administrator, verify it through a known internal channel before sharing anything.

Explain the consequences neutrally. If the platform requires two-step login and a person has not enabled it, the organisation may need to restrict or remove their access until the issue is resolved. That is different from advising someone to use another account, borrow another person’s login or conceal an association between accounts. The policy should direct people toward fixing the cause through approved channels.

Choose sensible authentication and backup methods

People should use authentication methods supported by the platform and appropriate to their circumstances. An authenticator application or a security key may be suitable where the platform supports it and the organisation can help staff manage it. A text message or other platform-supported method may be the available option for some people. The policy should not claim that any method is universally available or equally secure in every situation.

Backup planning should reduce the chance that a lost or unavailable device becomes a long-term access problem. Encourage people to review the platform’s official recovery options while they can still sign in. If recovery codes are provided, they should be stored securely and separately from the device used for routine authentication. They should not be posted in shared notes, sent through ordinary work chat or given to an administrator for safekeeping.

Where an organisation provides managed security keys or devices, it should define how they are issued, stored, replaced and returned. A backup device should be controlled by the individual or handled under a documented internal process, not passed around as a shared login method. Any backup must still meet platform rules and should not weaken the identity checks required by the platform.

Do not ask staff to keep a second person’s device as a workaround, or to send authentication prompts to someone else for convenience. A method that depends on another person’s account can blur responsibility and make investigations harder. If the platform does not offer a suitable method for someone, contact official support and assess whether that person should retain access while the issue is unresolved.

Support a person who loses a device

A lost, stolen or damaged device should trigger a straightforward response. The affected person should use the platform’s official account recovery process and report the issue through the organisation’s designated support route. If the device may be in someone else’s hands, they should also follow the organisation’s device-security process, such as contacting the team responsible for managed equipment.

Internal support can help by confirming the person’s business role, checking whether their access is still required and guiding them to official recovery information. Administrators should use the platform’s approved access-management features if temporary access changes are needed. They should not attempt to bypass authentication, impersonate the person or ask them to disclose a code.

If the person cannot regain access promptly, the organisation should manage work continuity through legitimate administrative access and role assignments. This may mean another authorised colleague handles a task using their own account and permissions. It does not mean sharing credentials or creating a replacement identity to avoid a restriction.

Once access is restored, the person should review their security settings, remove a lost device from the account where the platform permits it, and refresh recovery information if needed. The organisation can record that the incident was resolved without recording secrets or unnecessary personal information.

Verify compliance without collecting secrets

A compliance check should establish whether the requirement is met, not gather authentication material. Use the platform’s administrative security view if it provides a reliable indication of status. If no suitable view exists, ask each person to confirm completion through an approved internal process, then follow up with anyone who has not responded.

Keep the access list current and compare it with the people covered by the policy. A person who no longer needs access should be removed through normal administration rather than left on the list as an unresolved exception. For active users, record only the information needed to track completion, such as their work identity and status. Do not record passwords, codes, recovery codes, screenshots containing sensitive details or personal device contents.

Make the check recurring as part of ordinary access reviews, especially when roles change or people leave the organisation. The frequency and process should reflect internal needs and the platform’s current requirements; consult official help and policy pages for any platform-specific expectations. A completed check is a snapshot, not proof that an account will remain secure.

If the platform reports that a person does not meet the requirement, direct them to the official setup or recovery process and explain any access consequences. If the status appears wrong or the person is blocked despite following the instructions, use official support. Do not respond by moving work to an unapproved account or altering identity information.

Maintain the policy as access and rules change

A two-step login requirement works best when it is part of a broader access policy. Review who has administrative privileges, remove access that is no longer justified, and make sure people understand how to report suspicious sign-in activity. Keep responsibilities clear when an agency or other external partner has a role in the business container: document who manages access, who supports staff and how access is changed when the arrangement ends.

The organisation should also revisit its policy when the platform changes its security settings or requirements. Current options, recovery procedures and deadlines are published on the platform’s own help and policy pages. Avoid relying on old screenshots or informal instructions as the sole source of guidance.

A well-run rollout is firm about the requirement and practical about the support. Everyone with access is expected to use an approved two-step method, and people who encounter a genuine problem have a clear route to resolve it. That approach protects shared assets while keeping responsibility with the person who signs in and with the organisation that grants access.