Justin Marks

Azure DevOps now supports AzureAD (AAD) users accessing organizations that are backed by Microsoft accounts (MSA). For administrators, this means that if your organization uses MSAs for corporate users, new employees can use their AAD credentials for access instead of creating a new MSA identity.

On the 24th of July 2018, we notified some customers via e-mail and on this blog about a planned action that we would start taking in relation to the malicious ESLint NPM package incident. This action is now underway.

As promised in the Protecting our users from the ESLint NPM package breach blog post last week, we have deployed new REST APIs to allow administrators of Visual Studio Team Services (VSTS) accounts to centrally revoke Personal Access Tokens (PAT) and JSON Web Tokens (JWT) created by users in their accounts.

On January 5, 2018, I announced that Visual Studio Team Services will no longer allow creation of new MSA users with custom domain names backed by AzureAD.  While most customers agree with the direction of this change, I got clear feedback that they could not connect their VSTS to AzureAD by the March 31 deadline. 

In February 2017, VSTS announced support for Azure Active Directory Conditional Access Policy (CAP).  One caveat that was called out in that announcement was that alternate authentication mechanisms, such as personal access tokens, would not enforce CAP.
As I discussed previously,

A few weeks ago, I posted about a change coming to organizations managing their identities with Microsoft Accounts (MSAs); as of March 30th, you will no longer able to create new MSAs with a custom domain name that is linked to an Azure Active Directory tenant. 

3-28-2018 UPDATE : The deadline listed below has been extended to the end of September.  Read my latest blog post for more information.
On September 15, 2016, the Azure Active Directory (Azure AD) team blocked the ability to create new Microsoft accounts using email addresses in domains that are configured in Azure AD.

Recently, we’ve heard feedback from customers that developers have a poor experience creating and managing their alternate authentication credentials and that administrators moving from TFS to the cloud aren’t provided the policies they need to enforce how alternate authentication is used by their end users. 

The first wave of work for process customization is complete: allowing you to modify fields, layout and states of existing work item types.  While it’s taken longer than we had anticipated, we’ve received a ton of great feedback and our plan is to continue to work through the backlog. 

NOTE: An updated roadmap as of June 2016 is now available.
Last month, we released our first major milestone for process customization – the ability to add a field and modify layout, checkout my blog post on the topic if you haven’t seen it yet.