Tag Archives: identity

Turning off less secure app access to G Suite accounts

What’s changing 

Starting in June 2020, we’ll limit the ability for less secure apps (LSAs) to access G Suite account data. LSAs are non-Google apps that can access your Google account with only a username and password. They make your account more vulnerable to hijacking attempts. Instead of LSAs, you can use apps that support OAuth—a modern and secure access method.

This is most likely to impact users of legacy email, calendar, and contacts apps—see below for more details. We’ve also emailed your organization’s primary admin with details around this change. That email includes a list of users who are likely to be affected.

Access to LSAs will be turned off in two stages:

  • After June 15, 2020 - Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off. 
  • After February 15, 2021 - Access to LSAs will be turned off for all G Suite accounts. 


This is a continuation of our previously announced process to limit access to less secure apps to protect G Suite accounts. See below for more details on the possible impact of this change, and some recommendations for change management with users of LSAs.

Who’s impacted 

End users

Why this matters 

Many users use non-Google apps, and give those apps permission to access G Suite data. For example, you may give the iOS mail app permission to see your work email. This provides users with more options, and helps users get work done in a way that works well for them.

When account access is provided through an LSA, it puts that account at risk of hijacking. That’s because LSAs provide a non-Google app access to your account through just a username and password, without any other authentication factor. If a bad actor got access to your username and password (for example, if you re-use the password on another site that is subject to a data breach), they could access your account data with just that username and password information through an LSA.

However, when account access is provided through OAuth, we get more details about the login and can validate it the same way we would with any other login to your account. This means we can better identify and prevent suspicious login attempts, preventing hijackers from accessing the account data even if they have your username and password. OAuth also helps us enforce G Suite admin defined login policies, such as the use of security keys, as well as other security controls such as whitelisting apps and offering scope-based account access.

As we’re constantly working to improve the security of your organization’s G Suite accounts, we’ve made the decision to remove LSA access by February 15, 2021. Given the many alternative apps and processes available which do use OAuth (outlined below), we hope that this won’t cause significant disruption while increasing your account security.

How to get started 


  • Admins: 
    • See the “Additional details” section below for more information and recommended actions. 
    •  See the email sent to your organization’s primary admin with a subject line of “Switch to apps that use secure OAuth access, as password-based access will no longer be supported” for a list of users who are likely to be affected by the change. 
  • End users: See the “User information and advice” section below for more details and recommended actions, or use our Help Center to learn more about less secure apps and your Google account. 


Additional details 

Admin and developer information 

Mobile device management (MDM) configuration - If your organization uses a mobile device management (MDM) provider to configure CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) profiles, these services will be phased out according to the timeline below:

  • June 15, 2020 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for new users. 
  • February 15, 2021 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for existing users. Admins will need to push a Google Account using their MDM provider, which will re-add their Google accounts to iOS devices using OAuth. 


Scanners and other devices - No change is required for scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails. If you replace your device, look for one that sends email using OAuth.

Developer instructions - To maintain compatibility with G Suite accounts, update your app to use OAuth 2.0 as a connection method. To get started, follow our developer guide on using OAuth 2.0 to access Google APIs. You can also refer to our guide on OAuth 2.0 for mobile & desktop apps. 


End User information and advice 

If you are using an app that accesses your Google account with only a username and password, take one of the following actions to switch to a more secure method and continue to access your email, calendar, or contacts. If you do not take one of the following actions, when LSA access is discontinued after February 15, 2021, you will begin receiving an error message that your username-password combination is incorrect.

Email 

  • If you are using stand-alone Outlook 2016 or earlier, you can use G Suite Sync for Microsoft Outlook. Alternatively, move to Office 365 (a web-based version of Outlook) or Outlook 2019, both of which support OAuth access. 
  • If you are using Thunderbird or another email client, re-add your Google Account and configure it to use IMAP with OAuth. 
  • If you are using the mail app on iOS or MacOS, or Outlook for Mac, and use only a password to login, you’ll need to remove and re-add your account. When you add it back, make sure to choose Google as the account type to automatically use OAuth. 


Calendar

  • If you use CalDAV to give an app or device access to your calendar, switch to a method that supports OAuth. We recommend the Google Calendar app [Web/iOS/Android] as the most secure app to use with your G Suite account. 
  • If your G Suite account is linked to the calendar app in iOS or MacOS and uses only a password to login, you’ll need to remove and re-add your account to your device. When you add it back, select “sign in with Google” to automatically use OAuth. Read more. 

Contacts 

  • If your G Suite account is syncing contacts to iOS or MacOS via CardDAV and uses only a password to login, you’ll need to remove your account. When you add it back, select “sign in with Google” to automatically use OAuth. Read More. 
  • If your G Suite account is syncing contacts to any other platform or app via CardDAV and uses only a password to login, switch to a method that supports OAuth. 

Other less secure apps 

  • If you use other apps on iOS or MacOS that access your G Suite account information through only a password, most access issues can be resolved by removing then re-adding your account. When you add it back, make sure to select Google as the account type to automatically use OAuth. 
  • For any other LSA, contact your admin or ask the developer of the app you are using to start supporting OAuth. 
  • If the developer won’t update their app, you will need to switch to a client that offers OAuth.  


Helpful links 




Availability 

Rollout details - all domains 

  • After June 15, 2020 
    • Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off. 
    • MDM configuration of CalDAV or CardDAV will no longer work for new users. 
  • After February 15, 2021 
    • Access to LSAs will be turned off for all G Suite accounts. 
    • MDM configuration of CalDAV and CardDAV will no longer work for existing users. All existing users will be required to re-add their Google accounts if they wish to sync contacts, calendar, or email. 

G Suite editions 
Applicable to all G Suite editions

On/off by default?
This feature will be ON by default and can’t be turned off.


Stay up to date with G Suite launches

Turning off less secure app access to G Suite accounts

What’s changing 

Starting in June 2020, we’ll limit the ability for less secure apps (LSAs) to access G Suite account data. LSAs are non-Google apps that can access your Google account with only a username and password. They make your account more vulnerable to hijacking attempts. Instead of LSAs, you can use apps that support OAuth—a modern and secure access method.

This is most likely to impact users of legacy email, calendar, and contacts apps—see below for more details. We’ve also emailed your organization’s primary admin with details around this change. That email includes a list of users who are likely to be affected.

Access to LSAs will be turned off in two stages:

  • After June 15, 2020 - Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off. 
  • After February 15, 2021 - Access to LSAs will be turned off for all G Suite accounts. 


This is a continuation of our previously announced process to limit access to less secure apps to protect G Suite accounts. See below for more details on the possible impact of this change, and some recommendations for change management with users of LSAs.

Who’s impacted 

End users

Why this matters 

Many users use non-Google apps, and give those apps permission to access G Suite data. For example, you may give the iOS mail app permission to see your work email. This provides users with more options, and helps users get work done in a way that works well for them.

When account access is provided through an LSA, it puts that account at risk of hijacking. That’s because LSAs provide a non-Google app access to your account through just a username and password, without any other authentication factor. If a bad actor got access to your username and password (for example, if you re-use the password on another site that is subject to a data breach), they could access your account data with just that username and password information through an LSA.

However, when account access is provided through OAuth, we get more details about the login and can validate it the same way we would with any other login to your account. This means we can better identify and prevent suspicious login attempts, preventing hijackers from accessing the account data even if they have your username and password. OAuth also helps us enforce G Suite admin defined login policies, such as the use of security keys, as well as other security controls such as whitelisting apps and offering scope-based account access.

As we’re constantly working to improve the security of your organization’s G Suite accounts, we’ve made the decision to remove LSA access by February 15, 2021. Given the many alternative apps and processes available which do use OAuth (outlined below), we hope that this won’t cause significant disruption while increasing your account security.

How to get started 


  • Admins: 
    • See the “Additional details” section below for more information and recommended actions. 
    •  See the email sent to your organization’s primary admin with a subject line of “Switch to apps that use secure OAuth access, as password-based access will no longer be supported” for a list of users who are likely to be affected by the change. 
  • End users: See the “User information and advice” section below for more details and recommended actions, or use our Help Center to learn more about less secure apps and your Google account. 


Additional details 

Admin and developer information 

Mobile device management (MDM) configuration - If your organization uses a mobile device management (MDM) provider to configure CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) profiles, these services will be phased out according to the timeline below:

  • June 15, 2020 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for new users. 
  • February 15, 2021 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for existing users. Admins will need to push a Google Account using their MDM provider, which will re-add their Google accounts to iOS devices using OAuth. 


Scanners and other devices - No change is required for scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails. If you replace your device, look for one that sends email using OAuth.

Developer instructions - To maintain compatibility with G Suite accounts, update your app to use OAuth 2.0 as a connection method. To get started, follow our developer guide on using OAuth 2.0 to access Google APIs. You can also refer to our guide on OAuth 2.0 for mobile & desktop apps. 


End User information and advice 

If you are using an app that accesses your Google account with only a username and password, take one of the following actions to switch to a more secure method and continue to access your email, calendar, or contacts. If you do not take one of the following actions, when LSA access is discontinued after February 15, 2021, you will begin receiving an error message that your username-password combination is incorrect.

Email 

  • If you are using stand-alone Outlook 2016 or earlier, you can use G Suite Sync for Microsoft Outlook. Alternatively, move to Office 365 (a web-based version of Outlook) or Outlook 2019, both of which support OAuth access. 
  • If you are using Thunderbird or another email client, re-add your Google Account and configure it to use IMAP with OAuth. 
  • If you are using the mail app on iOS or MacOS, or Outlook for Mac, and use only a password to login, you’ll need to remove and re-add your account. When you add it back, make sure to choose Google as the account type to automatically use OAuth. 


Calendar

  • If you use CalDAV to give an app or device access to your calendar, switch to a method that supports OAuth. We recommend the Google Calendar app [Web/iOS/Android] as the most secure app to use with your G Suite account. 
  • If your G Suite account is linked to the calendar app in iOS or MacOS and uses only a password to login, you’ll need to remove and re-add your account to your device. When you add it back, select “sign in with Google” to automatically use OAuth. Read more. 

Contacts 

  • If your G Suite account is syncing contacts to iOS or MacOS via CardDAV and uses only a password to login, you’ll need to remove your account. When you add it back, select “sign in with Google” to automatically use OAuth. Read More. 
  • If your G Suite account is syncing contacts to any other platform or app via CardDAV and uses only a password to login, switch to a method that supports OAuth. 

Other less secure apps 

  • If you use other apps on iOS or MacOS that access your G Suite account information through only a password, most access issues can be resolved by removing then re-adding your account. When you add it back, make sure to select Google as the account type to automatically use OAuth. 
  • For any other LSA, contact your admin or ask the developer of the app you are using to start supporting OAuth. 
  • If the developer won’t update their app, you will need to switch to a client that offers OAuth.  


Helpful links 




Availability 

Rollout details - all domains 

  • After June 15, 2020 
    • Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off. 
    • MDM configuration of CalDAV or CardDAV will no longer work for new users. 
  • After February 15, 2021 
    • Access to LSAs will be turned off for all G Suite accounts. 
    • MDM configuration of CalDAV and CardDAV will no longer work for existing users. All existing users will be required to re-add their Google accounts if they wish to sync contacts, calendar, or email. 

G Suite editions 
Applicable to all G Suite editions

On/off by default?
This feature will be ON by default and can’t be turned off.


Stay up to date with G Suite launches

Turning off less secure app access to G Suite accounts

What’s changing 

Starting in June 2020, we’ll limit the ability for less secure apps (LSAs) to access G Suite account data. LSAs are non-Google apps that can access your Google account with only a username and password. They make your account more vulnerable to hijacking attempts. Instead of LSAs, you can use apps that support OAuth—a modern and secure access method.

This is most likely to impact users of legacy email, calendar, and contacts apps—see below for more details. We’ve also emailed your organization’s primary admin with details around this change. That email includes a list of users who are likely to be affected.

Access to LSAs will be turned off in two stages:

  • After June 15, 2020 - Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off. 
  • After February 15, 2021 - Access to LSAs will be turned off for all G Suite accounts. 


This is a continuation of our previously announced process to limit access to less secure apps to protect G Suite accounts. See below for more details on the possible impact of this change, and some recommendations for change management with users of LSAs.

Who’s impacted 

End users

Why this matters 

Many users use non-Google apps, and give those apps permission to access G Suite data. For example, you may give the iOS mail app permission to see your work email. This provides users with more options, and helps users get work done in a way that works well for them.

When account access is provided through an LSA, it puts that account at risk of hijacking. That’s because LSAs provide a non-Google app access to your account through just a username and password, without any other authentication factor. If a bad actor got access to your username and password (for example, if you re-use the password on another site that is subject to a data breach), they could access your account data with just that username and password information through an LSA.

However, when account access is provided through OAuth, we get more details about the login and can validate it the same way we would with any other login to your account. This means we can better identify and prevent suspicious login attempts, preventing hijackers from accessing the account data even if they have your username and password. OAuth also helps us enforce G Suite admin defined login policies, such as the use of security keys, as well as other security controls such as whitelisting apps and offering scope-based account access.

As we’re constantly working to improve the security of your organization’s G Suite accounts, we’ve made the decision to remove LSA access by February 15, 2021. Given the many alternative apps and processes available which do use OAuth (outlined below), we hope that this won’t cause significant disruption while increasing your account security.

How to get started 


  • Admins: 
    • See the “Additional details” section below for more information and recommended actions. 
    •  See the email sent to your organization’s primary admin with a subject line of “Switch to apps that use secure OAuth access, as password-based access will no longer be supported” for a list of users who are likely to be affected by the change. 
  • End users: See the “User information and advice” section below for more details and recommended actions, or use our Help Center to learn more about less secure apps and your Google account. 


Additional details 

Admin and developer information 

Mobile device management (MDM) configuration - If your organization uses a mobile device management (MDM) provider to configure CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) profiles, these services will be phased out according to the timeline below:

  • June 15, 2020 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for new users. 
  • February 15, 2021 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for existing users. Admins will need to push a Google Account using their MDM provider, which will re-add their Google accounts to iOS devices using OAuth. 


Scanners and other devices - No change is required for scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails. If you replace your device, look for one that sends email using OAuth.

Developer instructions - To maintain compatibility with G Suite accounts, update your app to use OAuth 2.0 as a connection method. To get started, follow our developer guide on using OAuth 2.0 to access Google APIs. You can also refer to our guide on OAuth 2.0 for mobile & desktop apps. 


End User information and advice 

If you are using an app that accesses your Google account with only a username and password, take one of the following actions to switch to a more secure method and continue to access your email, calendar, or contacts. If you do not take one of the following actions, when LSA access is discontinued after February 15, 2021, you will begin receiving an error message that your username-password combination is incorrect.

Email 

  • If you are using stand-alone Outlook 2016 or earlier, you can use G Suite Sync for Microsoft Outlook. Alternatively, move to Office 365 (a web-based version of Outlook) or Outlook 2019, both of which support OAuth access. 
  • If you are using Thunderbird or another email client, re-add your Google Account and configure it to use IMAP with OAuth. 
  • If you are using the mail app on iOS or MacOS, or Outlook for Mac, and use only a password to login, you’ll need to remove and re-add your account. When you add it back, make sure to choose Google as the account type to automatically use OAuth. 


Calendar

  • If you use CalDAV to give an app or device access to your calendar, switch to a method that supports OAuth. We recommend the Google Calendar app [Web/iOS/Android] as the most secure app to use with your G Suite account. 
  • If your G Suite account is linked to the calendar app in iOS or MacOS and uses only a password to login, you’ll need to remove and re-add your account to your device. When you add it back, select “sign in with Google” to automatically use OAuth. Read more. 

Contacts 

  • If your G Suite account is syncing contacts to iOS or MacOS via CardDAV and uses only a password to login, you’ll need to remove your account. When you add it back, select “sign in with Google” to automatically use OAuth. Read More. 
  • If your G Suite account is syncing contacts to any other platform or app via CardDAV and uses only a password to login, switch to a method that supports OAuth. 

Other less secure apps 

  • If you use other apps on iOS or MacOS that access your G Suite account information through only a password, most access issues can be resolved by removing then re-adding your account. When you add it back, make sure to select Google as the account type to automatically use OAuth. 
  • For any other LSA, contact your admin or ask the developer of the app you are using to start supporting OAuth. 
  • If the developer won’t update their app, you will need to switch to a client that offers OAuth.  


Helpful links 




Availability 

Rollout details - all domains 

  • After June 15, 2020 
    • Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off. 
    • MDM configuration of CalDAV or CardDAV will no longer work for new users. 
  • After February 15, 2021 
    • Access to LSAs will be turned off for all G Suite accounts. 
    • MDM configuration of CalDAV and CardDAV will no longer work for existing users. All existing users will be required to re-add their Google accounts if they wish to sync contacts, calendar, or email. 

G Suite editions 
Applicable to all G Suite editions

On/off by default?
This feature will be ON by default and can’t be turned off.


Stay up to date with G Suite launches

New option to make security codes more secure

What’s changing 

We’re giving you another option to determine how security codes can be used in your organization. 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.

With this launch we’re adding an option to restrict the use of codes to the same device or network that they were generated on.

Who’s impacted 

Admins and end users

Why you’d use it 

Since we introduced security codes in June 2019, we’ve observed that they’re most commonly used with applications that use legacy authentication on devices that are capable of supporting Chrome or other browsers that allow security keys. The new restricted security code option allows that use case to be satisfied while reducing some potential vulnerabilities. Unrestricted codes will still be available for users who need them (such as those using remote servers or virtual machines).

How to get started 

Admins: Customers can turn this feature on at Admin console > Security > Advanced security settings. Use our Help Center to find out more about security codes. 
End users: No action needed.

Additional details 

Three security code settings available to G Suite admins 
With this launch, there will be three options for security codes:

  • Don't allow users to generate security codes. Users can’t generate security codes. This was previously available, and was the default setting. 
  • Allow security codes without remote access. Users can generate security codes and use them on the same device or local network (NAT or LAN). This is a new option, and replaces the don’t allow security codes as the default setting for new G Suite customers. 
  • Allow security codes with remote access. Users can generate security codes and use them on the same device or local network (NAT or LAN), as well as other devices or networks, such as when accessing a remote server or a virtual machine. The earlier version of security codes was effectively the same as this. 


No impact to existing users 
This launch won’t change the user experience unless an admin changes a setting in the Admin console. Specifically,

  • Users who are currently assigned “Don’t allow security codes” will now be assigned “Don't allow users to generate security codes” and will still not be able to use security codes. 
  • Users who are currently assigned “Allow use of security codes,” will now be assigned “Allow security codes with remote access” and will be able to use security codes in the same way as before. 

Use our Help Center to learn more about security codes and 2-Step Verification.

Security codes and the Advanced Protection Program for the enterprise 
You can control security code use separately for your users in the Advanced Protection Program for the enterprise. Security code settings for those users are determined by controls at Admin console > Security > Advanced Protection Program. Settings for security code use here will override regular settings for those users. Read more about the Advanced Protection Program for the enterprise.

Helpful links 

Help Center: Allow security codes when security keys aren't supported 
G Suite Updates blog: Use security codes to log in where security keys won’t work directly

Availability 

Rollout details 


G Suite editions 

  • Available to all G Suite editions. 

On/off by default? 

  • This feature will be OFF by default and can be customized on the domain, OU, or group level.


Stay up to date with G Suite launches

Advanced Protection Program for the enterprise generally available to help protect high-risk users

This announcement was made at Google Cloud Next ‘19 UK. Check out Next OnAir to tune into the livestream or watch session recordings following the event.


What’s changing 

The Advanced Protection Program for the enterprise is now generally available. It was previously available in beta.

Who’s impacted 

Admins and end users

Why you’d use it 

The Advanced Protection Program for the enterprise enforces a specific set of high security policies for employees in your organization that are most at risk for targeted attacks. Targeted attacks describe sophisticated, low volume handcrafted attacks that are often carried out by highly motivated professional or government backed groups. Employees at risk of targeted attacks that may benefit from the program include, for example, IT admins, executives, and employees in regulated industries such as finance or government.

The individual policies currently included in the Advanced Protection Program are also available to G Suite admins and users outside of the program. However, the Advanced Protection Program for the enterprise offers a simple bundle of our strongest account security settings for your organization’s high-risk users, and the program is constantly evolving to ensure these users continue to have Google’s strongest account security in place.

How to get started 


  • Admins: 
    • By default, all users will be able to enroll in the program. Admins can turn it off for users on a per-OU basis at Admin Console > Security > Advanced Protection Program. 
    • For beta users: During the beta, the feature was off by default unless admins specifically turned it on. Now, it will be on by default for all users. If you turned it on and then off again for some users during the beta, the setting will remain off for those users and they will not be able to enroll unless you turn it on. 
    • Use our Help Center to find out more about the Advanced Protection Program for enterprise. 
  • End users: Once enabled, users can complete their self-enrollment by visiting g.co/advancedprotection and clicking on ‘Get Started’. 


Additional details 

Policies enforced for users in the Advanced Protection Program 

Policies enforced for users in the program include:

  • Requiring the use of security keys (such as the Titan Security Key) for maximum protection against phishing. 
  • Automatically blocking access of most third party apps to Drive and Gmail data if those apps are not explicitly trusted by the admin. 
  • Enhanced email scanning for threats. 
  • Download protections from Google Safe Browsing for certain file types when signed into Google Chrome with the same identity. 


Use our Help Center to find out more details about these policies.

Requirements for users in the Advanced Protection Program 

The Advanced Protection Program is available for all users in all G Suite and Cloud Identity organizations unless admins turn it off for some or all users. When users enroll in the Advanced Protection program, they will need:

  • To register two security keys (one as a backup) 
  • To re-sign in on all their devices using a password and security key. They’ll be signed out of all devices when they enroll. 


Details and requirements will be explained to users as they enroll themselves in the program at g.co/advancedprotection.

New default: Allow security codes without remote access 

In the beta, you had an option to allow or not allow the use of security codes for your users who sign up for the Advanced Protection Program. Now, we’re adding a new option in addition to the previous two. The new option, allow security codes without remote access, will mean users can only use security codes they generate on the same device or local network.

This new option, allow security codes without remote access, will be the default for new and existing users. So any users who were not allowed to use security codes during the beta will be allowed to use security codes without remote access when general availability rolls out to your domain. Note that if you chose ‘allow security codes’ in the beta, that choice will persist when the GA version rolls out to your domain.

If you want to change this for all or some users, go to Admin Console > Security > Advanced Protection Program and choose between:

  • Don't allow users to generate security codes. 
  • Allow security codes without remote access (default). 
  • Allow security codes with remote access. 


See our Help Center for more information on the new Security Code options.


Admins can allow or prevent their users from being able to opt-in to Advanced Protection 

Helpful links 

Advanced Protection Program overview and sign up: g.co/advancedprotection 
Help Center: Protect users with the Advanced Protection Program

Availability 

Rollout details 

  • Rapid Release domains: Extended rollout (potentially longer than 15 days for feature visibility) starting on November 20, 2019 
  • Scheduled Release domains: Extended rollout (potentially longer than 15 days for feature visibility)] starting on November 20, 2019 
  • Note: If you see “Beta” when you go to Admin Console > Security > Advanced Protection Program, then the rollout has not yet reached your domain. 

G Suite editions 
Available to all G Suite editions

On/off by default? 
This feature will be ON by default and can be controlled at the OU level

Fundamental device management brings basic coverage to all desktop computers

What’s changing 

With this launch, all desktop devices that log in to G Suite will get fundamental device management by default. This means that when a user logs in to G Suite through any browser on a Windows, Mac, Chrome, or Linux device, the device will be registered with endpoint management. This will happen automatically upon login and does not require any other user actions or software to be installed on the device.

When a device is registered with fundamental device management, admins can see the device type, operating system, first sync time, and last sync time in the Admin console. They can also sign the user out from that device.

This provides the basic benefits of device management without additional costs or requiring installation of agents or profiles. We’re also making enhancements to the filters available in the device list that will strengthen our endpoint verification and Context-Aware Access functionality. See more information below.

Who’s impacted 

Admins only

Why you’d use it 

Fundamental device management provides a base level of security to every desktop device that accesses G Suite data. The device data collected can help admins make more informed security and policy decisions about how to manage the devices in their organization. More specifically, the feature will help admins to:
  • Get a clearer picture of all the devices that are accessing corporate data. 
  • Use more comprehensive data to analyze device access in the organization through reports and the security center. For example, you could use it to identify devices that require OS updates. 
  • Take remedial action to remotely sign out a user when a device is lost, stolen, or compromised.
  • Improve Context-Aware Access controls. The device inventory will be more comprehensive, and admins can use a new “Exclude Endpoint Verification” filter, which will enable admins to see which devices would not be able to access G Suite when context-aware access is deployed. 


How to get started 



Additional details 


Fundamental desktop management provides device information without apps or agents 

When fundamental device management is enabled, the admin will get information about a limited set of device properties: device type, device model, OS version, first sync, and last sync.

This will be visible in two places in the Admin console:

  • The devices list found at Admin console > Device management > Devices > Endpoints. 
  • The audit section found at Admin console > Reporting > Audit > Devices. 

Information about devices with fundamental device management will be listed alongside devices that use other agents to provide admins with details about devices accessing corporate data. Admins can filter the endpoint list by “Management Type” to see devices with a specific device management type, such as fundamental, endpoint verification, or Drive File Stream.

You can filter for “Fundamental” managed devices at Admin console > Device management > Devices 

A device page with information provided through fundamental device management 


Limitations of fundamental device management and other endpoint verification options 
Fundamental device management is designed to be an agentless, lightweight information collection tool. Its goal is to provide a basic data set, which can help admins make some decisions and add some controls to devices accessing their data.

Google provides other services, which offer more detailed data and enable more comprehensive controls to admins, including endpoint verification, Chrome device management, Drive File Stream, and Google Mobile Management.

New Endpoint Verification filter helps deploy Endpoint Verification and Context-Aware Access

We’re also adding the ability to filter for devices without endpoint verification in the device list at Admin console > Device management > Devices. This can help admins to identify devices which are accessing corporate data without endpoint verification, and see if they’d like to install endpoint verification on any of them. This can also improve the deployment of Context-Aware Access, which relies on Endpoint Verification. By seeing users and devices without Endpoint Verification installed, admins can identify and avoid potential user disruption before turning on Context-Aware Access. 

Helpful links 



Availability 

Rollout details 

  • Rapid and Scheduled Release domains: 
    • Extended rollout (longer than 15 days for feature visibility) starting on October 29, 2019. 
    • Rollout could take up to 6 months to reach all domains. 
    • When it reaches your domain, you’ll see the banner pictures below, and there will be a new “Management Type > Fundamental” filter option available in the endpoint devices list. 

When the rollout reaches your domain, you’ll see this banner when you go to Admin console > Device management > Devices 

When the rollout reaches your domain, you’ll see the “Fundamental” management type filter option at Admin Console > Device Management > Devices. 


G Suite editions 
Available to all G Suite editions.

On/off by default? 
This feature will be enabled by default.


Stay up to date with G Suite launches

Dynamic, context-aware access control for G Suite now generally available

What’s changing 

Context-aware access for G Suite is now generally available for G Suite Enterprise and G Suite Enterprise for Education domains. It was previously available in beta.

With context-aware access, you can set up different access levels based on a user’s identity and the context of the request (location, device security status, IP address). This can help you provide granular access controls without the need for a VPN, and give users access to G Suite resources based on organizational policies. For example, you could use it to:

  • Let only certain employees access Gmail outside of the corporate WiFi network. 
  • Allow access to Drive only if a user’s desktop device storage is encrypted. 
  • Permit users from a certain Organizational Unit (e.g. executives) to access apps on any network, but restrict access to apps for other OUs from outside the corporate network. 

Visit our Help Center for more information on how to use context-aware access. For more details on context-aware access and a number of other G Suite security announcements, please read our Cloud Blog post.

Who’s impacted 

Admins only

Why you’d use it

See this video for some ideas about how you could use context-aware access:

How to get started 


  • Admins: Use our Help Center to learn how to start using context-aware access. 
  • End users: No action needed 

Helpful links 

Help Center: Context-Aware Access overview 

Availability 

Rollout details 


G Suite editions

  • Available to G Suite Enterprise, G Suite Enterprise for Education, and Cloud Identity Premium 
  • Not available to G Suite Basic, G Suite Business, G Suite for Education, G Suite for Nonprofits, and Cloud Identity Free 

On/off by default?
This feature will be OFF by default and can be enabled at the OU level.

Use Google 2-Step Verification and risk-based login challenges with 3rd-party identity providers

What’s changing 

We’re making two Google login security measures available to organizations that use 3rd-party identity providers. Admins at these organizations can choose to turn on two features that significantly improve account security against various attacks on user accounts. These features are new for customers using 3-party identity providers:

  • 2-Step Verification, an extra verification step that automatically requests verification when certain conditions are met (for example, when someone tries to log in on a new device or browser). Learn more about 2-Step Verification. 
  • Risk-based login challenges, which uses machine learning to analyze user access patterns and assess the risk of a malicious attack, and presents additional verification challenges when the behavior looks suspicious. Learn more about risk-based login challenges. 


Who’s impacted 

Admins and end users

Why you’d use it 

This will allow you to better protect your users' accounts from unauthorized access. You can use this feature to:

  • Increase overall account security, by leveraging Google's risk-based challenges for users authenticating on your 3rd-party identity provider. 
  • Enforce Google 2-Step Verification for certain users only. For example, you can enforce Google 2-Step Verification in combination with your 3rd-party identity provider for users with access to more sensitive information stored within Google. 
  • Use 2-Step Verification without additional costs. You can enforce these policies for users predominantly accessing Google resources at no additional cost. 

How to get started 


  • Admins: You can choose whether to enforce additional 2-Step Verification for users at Admin console > Security > Login challenges > Post-SSO verification. Use our Help Center to learn more about 2-Step Verification with 3rd-party identity providers. 
  • End users: If turned on, a user will simply have to complete the 2-Step Verification step using a familiar Google sign-in interface after they sign in to the 3rd-party identity provider. Learn more about Google 2-Step Verification. 


Admin controls available for verification enforcement when using a 3rd-party identity provider 

Helpful links 




Availability 

Rollout details


G Suite editions 
Available to all G Suite and Cloud Identity editions.

On/off by default? 
This feature will be OFF by default and can be enabled at the OU level.


Stay up to date with G Suite launches

Control session length for Google Cloud Console and gcloud CLI

What’s changing 

We’re opening a public beta so G Suite, Google Cloud Platform (GCP), and Cloud Identity admins can set a fixed session duration for specific apps and services. After the session expires, users will need to re-enter their login credentials to continue to access:
Settings can be customized for specific organizational units.

Note that this is designed to work on the web. However, the settings will apply to authentication on all platforms, including the web and mobile apps where they exist. As a result, affected mobile apps may not work properly when the feature is enabled.

Who’s impacted 

Admins only

Why you’d use it 

Many apps and services include sensitive data, and it’s important that only specific users can access that information. By requiring re-authentication, you can make it more difficult for the wrong people to obtain that data if they gain unauthorized access to a device.

How to get started 

  • Admins: Find session length controls at Admin console > Security > Google Cloud session control (Beta). See our Help Center to learn more about how to set session length for Google Cloud services. 
  • End users: If a session ends, users will simply need to log in to their account again using the familiar Google login flow. 

Additional details 

Third-party SAML identity providers and session length controls 
If your organization uses a third-party SAML-based identity provider, the cloud sessions will expire, but the user may be transparently reauthenticated (i.e. without actually being asked to present their credentials) if their session with the IdP is valid at that time. This is working as intended, as Google will redirect the user to the IdP and accept a valid assertion from the IdP. To ensure that the user is rechallenged for authentication, be sure to match the session timeout at the IdP with the session length you’d like to enforce.

Provides fixed-time controls (not activity-based) 
Note that the new session control is a fixed time limit—it does not look for session activity, or ‘idle time’. At this time, Google Cloud and G Suite do not support activity-based session expiry.

Re-authentication options 
When choosing a session length, admins will be able to choose:
  • Between a range of predefined session lengths, or set a custom session length. 
  • Whether users need regular login credentials (password and, if configured, 2-Step Verification), or require a security key to re-authenticate. 


Helpful links 

Help Center: Beta: Set session length for Google Cloud services 

Availability 

Rollout details 


Editions 
Available to all G Suite and Cloud Identity editions

On/off by default? 
This feature will be OFF by default and can be enabled at the OU level.

Stay up to date with G Suite launches

Automatically provision users with five additional apps

What’s changing 

We’re adding auto-provisioning support for five new applications:
  • Adobe 
  • Comeet
  • Foodee
  • RECOG
  • Spoke

Who’s impacted 

Admins only

Why you’d use it 

When auto-provisioning is enabled for a supported third-party application, any users created, modified, or deleted in G Suite are automatically added, edited, or deleted in the third-party application as well. This feature is highly popular with admins, as it removes the overhead of managing users across multiple third-party SaaS applications.

How to get started 

  • Admins: For more information on how to set up auto-provisioning, check out the Help Center.
  • End users: No action needed.

Helpful links 

Help Center: Automated user provisioning 
Help Center: Using SAML to set up federated SSO 

Availability 

Rollout details 

G Suite editions 
  • G Suite Education, Business, and Enterprise customers can enable auto-provisioning for all supported applications 
  • G Suite Basic, Government, and Nonprofit customers can enable auto-provisioning for up to three applications 

On/off by default? 
This feature will be OFF by default and can be enabled at the OU level.

Stay up to date with G Suite launches