Tag Archives: Security and Compliance

Use security codes to log in where security keys won’t work directly

What’s changing 

We’re adding an option for G Suite users to log in using security codes. A security code is a one-time use code, generated using a security key, that can be used to log in on legacy platforms where security keys aren’t supported directly.

Security codes will be available by default for some users:

  • Users subject to “Any” or “Any except verification codes via text, phone call” 2-Step Verification policies 
  • Users which are not subject to a specific 2-Step Verification policy, but that have chosen to use a security key. 


If you currently use an “only security key” policy and wish to allow security codes, an admin can choose turn security codes on for specific users (see more below).

Find out more about how to select a 2-Step Verification method to enforce here.

Who’s impacted 

Admins and end users

Why you’d use it 

Security keys increase account security significantly. While most modern systems support the use of security keys, some do not. For example, security keys often don’t work with Internet Explorer and Safari, iOS apps, remote desktops, and legacy applications that don’t support FIDO protocols. With this launch, users can now generate a security code with their security key, which can then be used to authenticate their login attempt where the security key itself won’t work.

For example, a user may need to access a web application that federates their Google identity, but only works on Internet Explorer 11. While the browser can’t communicate with a security key directly, the user can open a Chrome browser and generate a security code, which can then be entered in Internet Explorer to gain access to the application.

Security considerations 
Before enabling this new policy, carefully evaluate if your organization needs security codes. Using security keys without security codes helps to provide maximum protection against phishing. However if your organization has important workflows where security keys can’t be used directly, enabling security codes for those situations may help improve your security posture overall. 

How to get started 

Admins:

  • Domains that currently enforce an “only security key” policy can turn on security codes by going to Admin Console > Security > Advanced security settings and selecting “Users may utilize security code”. Use our Help Center to find out more about security codes. Domains that currently enforce other 2-step verification policies will have the feature turned on by default. 

End users:

  • For users in domains which enforce “Any” or “Any except verification codes via text, phone call” 2-Step Verification policies the feature will be enabled by default. 
  • For users in domains which enforce an “only security key” policy, no action is needed until an admin turns the feature on. 
  • Once enabled, when a user who can use security codes navigates to a page which requires a security key, they will see “Having trouble” or “Try another way.” Once they click on one of those options, they will be able to “Get a one-time security code”. This will link to a page that prompts them to enter their security code, and also tells them where to go (https://g.co/sc) to generate a security code if they don’t have one yet. 



Helpful links 

Help Center: Deploy two-step verification and allow security codes 
Help Center: Security controls and two-step verification

Availability 

Rollout details 

  • Rapid Release domains
    • For domains which currently enforce an “Any” or “Any except verification codes via text, phone call” policy, the feature will be enabled for users in a gradual rollout (up to 15 days for feature visibility) starting on June 24, 2019 
    • For domains which enforce an “only security key” policy, the admin console setting to allow users to utilize security codes will appear in the admin console in a gradual rollout (up to 15 days for feature visibility) starting on July 8, 2019. 
  • Scheduled Release domains
    • For domains which currently enforce an “Any” or “Any except verification codes via text, phone call” policy, the feature will be enabled for users in a gradual rollout (up to 15 days for feature visibility) starting on June 24, 2019 
    • For domains which enforce an “only security key” policy, the admin console setting to allow users to utilize security codes will appear in the admin console in a gradual rollout (up to 15 days for feature visibility) starting on July 8, 2019. 


G Suite editions 
Available to all G Suite editions

On/off by default? 

  • Security codes will be ON by default for domains which currently enforce “Any” or “Any except verification codes via text, phone call” 2-Step Verification policies. 
  • Security codes will be OFF by default for domains which currently enforce an “only security key” policy, security codes will be off by default and admins enable them at the domain, OU, or group level.


Stay up to date with G Suite launches

Use an Android phone for 2-step verification on iOS devices

Quick launch summary 

Earlier this year we announced the ability to use your Android phone’s built-in security key for two-factor authentication in G Suite.

Now, you can use devices with Android 7.0+ (Nougat) to verify your sign-in to Google and Google Cloud services on Apple iPads and iPhones.
To learn more about using your Android phone’s built-in security key to verify sign-in on iOS devices, see our Security Blog


Availability 

Rollout details 
G Suite editions 
  • Available to all G Suite editions 
On/off by default? 
  • If 2-Step Verification or Security Key Enforcement is turned on for an organization, Android phone will be available as an option for security keys by default. 

Use an Android phone for 2-step verification on iOS devices

Quick launch summary 

Earlier this year we announced the ability to use your Android phone’s built-in security key for two-factor authentication in G Suite.

Now, you can use devices with Android 7.0+ (Nougat) to verify your sign-in to Google and Google Cloud services on Apple iPads and iPhones.
To learn more about using your Android phone’s built-in security key to verify sign-in on iOS devices, see our Security Blog


Availability 

Rollout details 
G Suite editions 
  • Available to all G Suite editions 
On/off by default? 
  • If 2-Step Verification or Security Key Enforcement is turned on for an organization, Android phone will be available as an option for security keys by default. 

Take action by July 8, 2019, to ensure your users can continue to use third-party apps accessing Gmail data

What’s changing

Security and privacy are extremely important to Google. To better protect your data, we’ve made an important update to our policies governing third-party apps (web, Android, iOS, Chrome, and other apps) accessing Gmail data using G Suite APIs and OAuth2.

We previously announced that apps accessing user data for non-enterprise accounts using certain Gmail APIs had to be verified to ensure compliance with new privacy and security requirements using our OAuth API Application Verification. Starting on July 8, 2019, we’ll apply similar requirements for apps you may use within your domain.

Who’s impacted

Admins and end users

Why it matters

While existing unverified apps will continue to work for users who installed them before July 8, after this date we’ll block new installs for unverified third-party apps that access Gmail data and that you don’t explicitly trust (whitelist) in the G Suite Admin console.

How to get started


  • Admins:
    • Review unverified apps in your environment: Please review the unverified apps currently in use in your organization’s G Suite environment and decide which apps you want to trust and allow users to continue to install. The primary admin contact at your organization will receive an email by June 21, 2019, with a list of those unverified apps, including the number of users and whether or not you have trusted them in API Permissions.
    • Trust apps that you want to allow users to continue to install: To trust an app, use our API Permissions (OAuth apps whitelisting) feature in the Security section of the Admin console. Trusting an app also means that, if users consent, the app will have access to some G Suite user data (OAuth2 scopes) that you’ve otherwise restricted using this same tool. For example, if you’ve generally blocked access to Gmail OAuth2 scopes, trusted apps will have access for accounts where users consent.