Azure Information Protection enables you to discover, classify, label, and protect sensitive information using built-in information types and custom regexes. While our built-in sensitive information types cover a broad range of information, such as financial data, PII, and health-care data, a common request has been to be able to detect credential information.

This request is hardly surprisingly since the security of your data often depends on the integrity of credentials such as secret keys, passwords, and certificates, which are used for authentication and authorization. Often, poorly secured credentials are the root cause of a security breach and data loss.


Azure Information Protection can now detect different types of credentials

Today we’re announcing the public preview of the first group of credentials that AIP can automatically detect. The following credentials types can now be discovered by both Azure Information Protection client and the Azure Information Protection scanner:

  • Azure Service Bus Connection String
  • Azure IoT Connection String
  • Azure Storage Account
  • Azure IAAS Database Connection String and Azure SQL Connection String
  • Azure Redis Cache Connection String
  • Azure SAS
  • SQL Server Connection String
  • Azure DocumentDB Auth Key
  • Azure DocumentDB Auth Key
  • Azure Publish Setting Password
  • Azure Storage Account Key (Generic)

Getting Started

You can help your end-users be more compliant with your credentials handling policy. For example, if an end-user copies a connection string from a configuration file to their Excel or Word document, you can use conditions defined for your sensitivity labels to either recommend to your users that they should avoid storing passwords in unprotected Office files, or that they should protect the files with AIP, or you can automatically protect the files that contain credentials.


Admin settings.png

Figure 1: Recommendation defined by an admin when credentials are detected


client side behaviour.png

Figure 2: Resulting end user experience when SQL connection string is copied from a web.config file


You can further use the Azure Information Protection scanner to detect these credentials in on-premises file repositories, and then take action based on the generated reports. In addition to detecting these credentials, you can use the scanner to automatically protect files that contain credentials. Keep in mind that credentials can be stored in files with non-standard file name extensions. The Azure Information Protection scanner uses IFilters to extract file content and match content. You can link the built-in text IFilter to non-standard file name extensions to enable the scanner to inspect these files. To learn more about IFilters and how to map them to file name extensions see our Registering Filter Handlers documentation.

You can then use Azure Information Protection analytics and discovery to review the scanning results.


scanner cred scan results.png

Figure 3: Example Discovery report showing detected credentials


Microsoft IT protects credential information using Azure Information Protection

The new credential information types was one of the main use cases for Azure Information Protection scanner implementation in Microsoft. In conjunction with information about the last modified date of the file, it helped Microsoft IT evaluate the risk of credentials stored in files. The owner / editor of files reported by the scanner helped IT contact the right person to remove credentials from their files and change the exposed credentials used in applications, systems and services.

Looking forward

Introducing these credentials sensitive info types in Azure Information Protection is just the first step in helping you secure your credentials. We are expecting these patterns to become gradually available across other Microsoft Information Protection services, like Microsoft Cloud App Security and Office 365 DLP. More information types are planned to be released later and to be extended beyond the current list of Azure credentials.

Next steps

Download and install the latest Azure Information Protection preview client to try out these new capabilities: https://aka.ms/aipclient.


Looking for additional details to implement this solution? Turn to our technical documentation:
Your feedback is valuable and allows us to understand better what you need to help you in your information protection strategy. We encourage you to try the new features and share your feedback using our Yammer community.
Occasional Contributor

@Denis Mizetski Nice work AIP team. Thanks for the updates and new capabilities.


You say "since the security of your data often depends on the integrity of credentials such as secret keys, passwords, and certificates, which are used for authentication and authorization. Often, poorly secured credentials are the root cause of a security breach and data loss." Is it your expectation that general purpose user credentials (e.g., an Office 365 account in Azure AD) will be detectable in the future by this capability, or only system and service credentials as is generally reflected in the initial short list of Azure credentials?


Great question. Right now we released patterns that detect Azure secrets and SQL connection strings, but internally we are dogfooding additional patterns, and general username / password credentials. We would like to provide high quality and accurate detection with minimum of false positive, thus we released now only patterns that passed these requirements. Once we get good detections for other patterns, including username and passwords patterns we will open them to public availability.


Senior Member

thanks for sharing with us I have two comments 

first it will be so better 

if it is allow to choose more than condition at once 

second it will be perfect if there is an option per password and per customized domain 


You can chose more than one condition at one time now... 


For the second one: can you please elaborate on choosing per domain?

Occasional Contributor

Awesome, are these sensitivity types available in MCAS (rules from SCC) as well?


The info types are scheduled to be added to SCC very soon (no exact timeline for now). Once they are there you should be able to leverage them in MCAS too.