Because secure applications are essential to the organization, any downtime to them because of security issues can affect the business or some critical service that the business depends upon. So, it's important to allocate time and resources to ensure applications always stay in a healthy and secure state. Conduct a periodic security and health assessment of applications, much like a Security Threat Model assessment for code. For a broader perspective on security for organizations, see the [security development lifecycle (SDL)](https://www.microsoft.com/securityengineering/sdl).
This article describes security best practices for the following application properties:
- Credentials
- Redirect URIs
- Implicit flow configuration
- Application instance lock
- Application ownership
## Credentials (including certificates and secrets)
Credentials are a vital part of an application when it's used as a confidential client. Under the **Certificates and secrets** page for the application in the Azure portal, credentials can be added or removed.
- If the service the app is used in doesn't run on Azure, but does run on another platform that offers automated credential management, consider [using an identity from that platform as a credential](../workload-id/workload-identity-federation-create-trust). For example, a [Github actions workflow can be configured as a credential](../workload-id/workload-identity-federation-create-trust#github-actions), eliminating the need to manage and secure credentials for the Github actions pipeline. Use caution with this approach and only configure federated credentials from platforms you trust. An app is only as secure as the identity platform it has configured as a credential.
- If using a managed identity or other secure external identity provider isn't possible, use [certificate credentials](./certificate-credentials.md). **Don't use password credentials, also known as *secrets***. While it's convenient to use password secrets as a credential, password credentials are often mismanaged and can be easily compromised.
- If a certificate must be used instead of a managed identity, store that certificate in a secure key vault, like [Azure Key Vault](https://azure.microsoft.com/products/key-vault).
- Configure [application management policies](/graph/api/resources/applicationauthenticationmethodpolicy) to govern the use of secrets by limiting their lifetimes or blocking their use altogether.
- If an application is used only as a public or installed client (for example, mobile or desktop apps that are installed on the end user machine), make sure that there are no credentials specified on the application object.
- Review the credentials used in applications for freshness of use and their expiration. An unused credential on an application can result in a security breach. Rollover credentials frequently and don't share credentials across applications. Don't have many credentials on one application.
Because secure applications are essential to the organization, any downtime to them because of security issues can affect the business or some critical service that the business depends upon. So, it's important to allocate time and resources to ensure applications always stay in a healthy and secure state. Conduct a periodic security and health assessment of applications, much like a Security Threat Model assessment for code. For a broader perspective on security for organizations, see the [security development lifecycle (SDL)](https://www.microsoft.com/securityengineering/sdl).
This article describes security best practices for the following application properties and scenarios:
- Identity type
- Credentials
- Redirect URIs
- Implicit flow configuration
- Application instance lock
- Application ownership
## Identity type
You are likely here to learn about security best practices for [Entra applications](../identity-platform/how-applications-are-added) - also referred to as app registrations or app objects. However, there is another identity type that can be used to access Entra-protected resources, called [managed identities for Azure resources](https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/overview).
Azure managed identities are secure by default and require little to no ongoing maintenance or overhead. Consider using a managed identity instead of an Entra application for your app identity if all of the following are true:
- The service runs in the Azure cloud
- The app doesn't need to sign in users