How to Require Remote MFA with Cloud Identity 2-Step Verification

How to Require Remote MFA with Cloud Identity 2-Step Verification

Configure cloud identity 2-step verification remote mfa by enforcing 2SV for remote-access users and retaining ISO 27001 evidence.

LakeRidge Team
July 17, 2026
7 min read

Share:

Schedule Your Free Compliance Consultation

Feeling overwhelmed by compliance requirements? Not sure where to start? Get expert guidance tailored to your specific needs in just 15 minutes.

Personalized Compliance Roadmap
Expert Answers to Your Questions
No Obligation, 100% Free

CMMC Phase 2 begins November 10, 2026.

To satisfy ISO 27001:2022 control 6.7 for remote personnel, enforce Google Cloud Identity 2-Step Verification for every human account that can access company information outside approved premises, then retain proof that the policy is active and users enrolled. A cloud identity 2-step verification remote mfa policy can provide the authentication safeguard portion of the control when it is scoped to the correct users, enforced rather than merely offered, and supported by endpoint and data-protection measures.

For a vCISO, the key distinction is simple: an optional enrollment campaign is not a control. Google Cloud Identity must require 2-Step Verification at sign-in for the applicable organizational unit, and the client must be able to demonstrate both the policy setting and actual user enrollment.

How do you configure cloud identity 2-step verification remote mfa?

Use the Google Admin console to place remote-capable personnel in an organizational unit (OU), enforce 2-Step Verification for that OU, and select a strong authentication method. The following procedure assumes the organization uses Cloud Identity or Google Workspace identities to access Google Cloud, Google Workspace, SaaS applications federated through Google, or administrative portals.

  1. Create an OU for the users subject to the requirement. In the Google Admin console, go to Directory > Organizational units, select Create new organizational unit, and create an OU such as Remote Workforce - MFA Required. Do not use an OU that also contains service accounts, shared mailbox identities, or unmanaged technical accounts.

  2. Move in-scope human users into the OU. Go to Directory > Users, select the users, choose More options > Change organizational unit, and move them to Remote Workforce - MFA Required. Include employees, contractors, administrators, and support personnel who can work remotely or access production information from outside company premises.

  3. Open the 2-Step Verification policy. Go to Security > Authentication > 2-Step Verification. If Google displays an organization-wide setting first, use the organizational-unit selector at the left and select Remote Workforce - MFA Required.

  4. Allow enrollment and enforce it. Under 2-Step Verification, set Allow users to turn on 2-Step Verification to On. Set Enforcement to On. Click Save.

  5. Set the new-user enrollment period deliberately. When enforcement is enabled, set New user enrollment period to the shortest operationally workable value. A seven-day enrollment period is reasonable for a client that needs time to issue security keys and complete onboarding; one day is appropriate when devices and keys are issued before the account is activated. Document the selected value. During this period, the account is not yet fully protected by enforced remote MFA.

  6. Configure permitted authentication methods. From Security > Authentication > 2-Step Verification, open 2-Step Verification methods. For privileged users, select the option that requires a Security key where available. For the general remote workforce, permit phishing-resistant methods such as security keys, passkeys, Google Prompt, or authenticator-app codes according to the client’s risk assessment. Avoid treating SMS as the preferred method for administrators because it is more susceptible to SIM-swap and phone-number takeover attacks.

  7. Protect emergency access separately. Maintain at least two emergency administrator accounts in a tightly controlled OU, register hardware security keys for each, store those keys under documented custody, and monitor their use. Do not exempt ordinary administrators from enforcement merely to preserve a convenient recovery path.

For example, an illustrative 68-person colocation operator, Northline Data Centers, uses Google Cloud Identity for Google Cloud console access, Jira Service Management, Grafana Cloud, and a privileged remote-hands scheduling workflow. Its vCISO placed operations engineers, facilities managers, finance personnel, and all Google Cloud administrators in Remote Workforce - MFA Required; only non-human monitoring integrations remained outside that OU. The client then required security keys for the six users holding production Google Cloud roles and allowed authenticator applications or Google Prompt for lower-risk business users.

How can you verify that the Google Cloud Identity 2SV policy took effect?

Verify the policy at three levels: the OU setting, the user enrollment state, and sign-in activity. A green “saved” confirmation alone is insufficient because inherited policies, user placement, enrollment grace periods, and excluded accounts can create gaps.

  1. Confirm the policy is effective for the intended OU. Return to Security > Authentication > 2-Step Verification, select Remote Workforce - MFA Required, and confirm that Enforcement displays On. Also inspect the parent OU to ensure an inherited setting is not weakening the child policy.

  2. Check individual enrollment status. Go to Directory > Users, open a sample user, and select Security. Confirm that the user’s 2-Step Verification status is enrolled and review the registered methods. Test at least one standard remote user, one privileged administrator, a recent hire, and a contractor.

  3. Review authentication activity. Go to Reporting > Audit and investigation > Login log. Filter by the user’s email address and the relevant date range. Review successful logins, failed attempts, and challenge-related events to validate that remote access generates a second-factor challenge rather than a password-only session.

  4. Perform a controlled test. Use a test account in the enforced OU from an unmanaged or off-network device. Sign in with the account password and confirm that access cannot proceed until the registered second factor is completed. Record the test date, tester, account used, result, and any exception observed.

A Cloud Identity two-step verification rollout should be tested after every significant change to organizational units, identity synchronization, SSO configuration, or administrator role assignment. These are common points where a newly created account or contractor population can land outside the intended policy scope.

What evidence should a vCISO capture for an ISO 27001 assessor?

For ISO 27001 control 6.7, evidence should show that the organization has implemented and operates security measures for remote work, not merely that it owns an identity platform. Capture dated evidence at implementation and repeat it during periodic control testing.

Evidence item Google Admin console source What it demonstrates
Policy screenshot showing enforcement Security > Authentication > 2-Step Verification The applicable OU has Enforcement: On, the enrollment period, and approved 2SV method policy.
OU membership export or screenshot Directory > Organizational units and Directory > Users Remote workers, contractors, and administrators are in the policy scope.
User enrollment evidence Directory > Users > [User] > Security Sampled users have enrolled 2-Step Verification and registered appropriate factors.
Login audit export Reporting > Audit and investigation > Login log The control is operating through recent successful and challenged sign-in events.
Remote-work and access-control policy Client governance repository The business rule defines who may work remotely, expected MFA use, exception approval, and disciplinary or remediation processes.

At HarborStack Hosting, an illustrative 240-person managed hosting provider, the compliance manager exports the login log monthly for privileged Google Cloud users and attaches it to the access-control review. The vCISO also samples the on-call escalation workflow: an engineer receiving a production incident through PagerDuty must sign in through Cloud Identity with a security key before reaching the Google Cloud console or customer environment documentation. This links technical enforcement to a real remote-work process rather than leaving it as a static configuration screenshot.

Where does Cloud Identity 2-Step Verification fall short for remote working?

Cloud Identity 2SV verifies the user at sign-in; it does not by itself determine whether a person is remote, confirm that the endpoint is secure, encrypt locally stored data, prevent screen viewing by unauthorized people, or stop data from being copied to unmanaged devices. It also does not protect applications that do not use Google as their identity provider.

Fill those gaps with endpoint management and documented remote-working safeguards. For higher-risk clients, combine the remote MFA policy with managed-device requirements, full-disk encryption, supported operating-system patching, EDR, screen-lock settings, secure home-network guidance, and an approved process for handling paper records. Where licensing and architecture support it, use Google Context-Aware Access to limit sensitive services to managed devices or defined access levels; use a VPN, zero-trust access proxy, or separate application MFA for systems outside Google federated authentication.

Review each client’s Cloud Identity OU design this quarter, enforce 2-Step Verification for every remote-capable human account, and add the resulting evidence to the ISO 27001 control-testing file.

 

Quick & Simple

Discover Our Cybersecurity Compliance Solutions:

Whether you need to meet and maintain your compliance requirements, help your clients meet them, or verify supplier compliance we have the expertise and solution for you

 CMMC Level 1 Compliance App

CMMC Level 1 Compliance

Become compliant, provide compliance services, or verify partner compliance with CMMC Level 1 Basic Safeguarding of Covered Contractor Information Systems requirements.
 NIST SP 800-171 & CMMC Level 2 Compliance App

NIST SP 800-171 & CMMC Level 2 Compliance

Become compliant, provide compliance services, or verify partner compliance with NIST SP 800-171 and CMMC Level 2 requirements.
 HIPAA Compliance App

HIPAA Compliance

Become compliant, provide compliance services, or verify partner compliance with HIPAA security rule requirements.
 ISO 27001 Compliance App

ISO 27001 Compliance

Become compliant, provide compliance services, or verify partner compliance with ISO 27001 requirements.
 FAR 52.204-21 Compliance App

FAR 52.204-21 Compliance

Become compliant, provide compliance services, or verify partner compliance with FAR 52.204-21 Basic Safeguarding of Covered Contractor Information Systems requirements.
 ECC Compliance App

ECC Compliance

Become compliant, provide compliance services, or verify partner compliance with Essential Cybersecurity Controls (ECC – 2 : 2024) requirements.