-|[Microsoft Entra ID (Multi-tenant)](identity-provider-azure-ad-multi-tenant.md) | NA | GA | |

-| `UserInterfaceControlType` | Yes | The type of the display control. Currently supported is [VerificationControl](display-control-verification.md), and [TOTP controls](display-control-time-based-one-time-password.md). |

-description: Specify the IDs for a content definition with an ID of api.signuporsignin in a custom policy in Azure Active Directory B2C.

-#Customer intent: As a developer implementing user interface localization in Azure Active Directory B2C, I want to access the list of localization string IDs, so that I can use them in my policy to support multiple locales or languages in the user journeys.

-| `unknown_error` | We are having trouble signing you in. Please try again later. | `All` |

-| `invalid_password` | The password you entered is not in the expected format. | `< 2.0.0` |

-| `ver_fail_server` | We are having trouble verifying your email address. Please enter a valid email address and try again. |

-The following `UxElement` string IDs will display disclaimer link(s) at the bottom of the self-asserted page. These links are not displayed by default unless specified in the localized strings.

-The following example shows the use of some of the user interface elements in the sign-up page, after user clicks on send verification code button:

-The following IDs are used for a [one-time password technical profile](one-time-password-technical-profile.md) error messages

-| `UserMessageIfSessionDoesNotExist` | No | The message to display to the user if the code verification session has expired. It is either the code has expired or the code has never been generated for a given identifier. |

-| `UserMessageIfMaxRetryAttempted` | No | The message to display to the user if they've exceeded the maximum allowed verification attempts. |

-| `UserMessageIfInvalidCode` | No | The message to display to the user if they've provided an invalid code. |

-| `UserMessageIfVerificationFailedRetryAllowed` | No | The message to display to the user if they've provided an invalid code, and user is allowed to provide the correct code. |

-| `UserMessageIfSessionConflict` | No | The message to display to the user if the code cannot be verified.|

-This example shows localized messages for local account signup.

-description: Configure Azure Active Directory B2C with Asignio for multifactor authentication

-zone_pivot_groups: b2c-policy-type

-# Customer intent: I'm a developer integrating Asignio with Azure AD B2C for multifactor authentication. I want to configure an application with Asignio and set it up as an identity provider (IdP) in Azure AD B2C, so I can provide a passwordless, soft biometric, and multifactor authentication experience to customers.

-# Configure Asignio with Azure Active Directory B2C for multifactor authentication

-Learn to integrate Microsoft Entra ID (Azure AD B2C) authentication with [Asignio](https://www.web.asignio.com/). With this integration, provide passwordless, soft biometric, and multifactor authentication experience to customers. Asignio uses patented Asignio Signature and live facial verification for user authentication. The changeable biometric signature helps to reduce passwords, fraud, phishing, and credential reuse through omni-channel authentication.

-## Before you begin

-Choose a policy type selector to indicate the policy type setup. Azure AD B2C has two methods to define how users interact with your applications:

-* Predefined user flows

-* Configurable custom policies

-The steps in this article differ for each method.

-Learn more:

-* [User flows and custom policies overview](user-flow-overview.md)

-* [Azure AD B2C custom policy overview](custom-policy-overview.md)

-## Prerequisites

-* An Azure subscription.

-* If you don't have on, get an [Azure free account](https://azure.microsoft.com/free/)

-### For custom policies

-Complete [Tutorial: Create user flows and custom policies in Azure AD B2C](./tutorial-create-user-flows.md?pivots=b2c-custom-policy)

-## Scenario description

-This integration includes the following components:

-* **Azure AD B2C** - authorization server that verifies user credentials

-* **Web or mobile applications** - to secure with Asignio MFA

-* **Asignio web application** - signature biometric collection on the user touch device

-The following diagram illustrates the implementation.

- 

-1. User opens Azure AD B2C sign in page on their mobile or web application, and then signs in or signs up.

-2. Azure AD B2C redirects the user to Asignio using an OpenID Connect (OIDC) request.

-3. The user is redirected to the Asignio web application for biometric sign in. If the user hasn't registered their Asignio Signature, they can use an SMS One-Time-Password (OTP) to authenticate. After authentication, user receives a registration link to create their Asignio Signature.

-4. The user authenticates with Asignio Signature and facial verification, or voice and facial verification.

-5. The challenge response goes to Asignio.

-6. Asignio returns the OIDC response to Azure AD B2C sign in.

-7. Azure AD B2C sends an authentication verification request to Asignio to confirm receipt of the authentication data.

-8. The user is granted or denied access to the application.

-## Configure an application with Asignio

-Configurating an application with Asignio is with the Asignio Partner Administration site.

-1. Go to asignio.com [Asignio Partner Administration](https://partner.asignio.com) page to request access for your organization.

-2. With credentials, sign into Asignio Partner Administration.

-3. Create a record for the Azure AD B2C application using your Azure AD B2C tenant. When you use Azure AD B2C with Asignio, Azure AD B2C manages connected applications. Asignio apps represent apps in the Azure portal.

-4. In the Asignio Partner Administration site, generate a Client ID and Client Secret.

-5. Note and store Client ID and Client Secret. You'll use them later. Asignio doesn't store Client Secrets.

-6. Enter the redirect URI in your site the user is returned to after authentication. Use the following URI pattern.

-`[https://<your-b2c-domain>.b2clogin.com/<your-b2c-domain>.onmicrosoft.com/oauth2/authresp]`.

-7. Upload a company logo. It appears on Asignio authentication when users sign in.

-## Register a web application in Azure AD B2C

-Register applications in a tenant you manage, then they can interact with Azure AD B2C.

-Learn more: [Application types that can be used in Active Directory B2C](application-types.md)

-For this tutorial, you're registering `https://jwt.ms`, a Microsoft web application with decoded token contents that don't leave your browser.

-### Register a web application and enable ID token implicit grant

-Complete [Tutorial: Register a web application in Azure Active Directory B2C](tutorial-register-applications.md?tabs=app-reg-ga)

-## Configure Asignio as an identity provider in Azure AD B2C

-For the following instructions, use the Microsoft Entra tenant with the Azure subscription.

-1. Sign in to the [Azure portal](https://portal.azure.com/#home) as the Global Administrator of the Azure AD B2C tenant.

-2. In the Azure portal toolbar, select **Directories + subscriptions**.

-3. On **Portal settings | Directories + subscriptions**, in the **Directory name** list, locate your Microsoft Entra directory.

-4. Select **Switch**.

-5. In the top-left corner of the Azure portal, select **All services**.

-6. Search for and select **Azure AD B2C**.

-7. In the Azure portal, search for and select **Azure AD B2C**.

-8. In the left menu, select **Identity providers**.

-9. Select **New OpenID Connect Provider**.

-10. Select **Identity provider type** > **OpenID Connect**.

-11. For **Name**, enter the Asignio sign in, or a name you choose.

-12. For **Metadata URL**, enter `https://authorization.asignio.com/.well-known/openid-configuration`.

-13. For **Client ID**, enter the Client ID you generated.

-14. For **Client Secret**, enter the Client Secret you generated.

-15. For **Scope**, use **openid email profile**.

-16. For **Response type**, use **code**.

-17. For **Response mode**, use **query**.

-18. For Domain hint, use `https://asignio.com`.

-19. Select **OK**.

-20. Select **Map this identity provider's claims**.

-21. For **User ID**, use **sub**.

-22. For **Display Name**, use **name**.

-23. For **Given Name**, use **given_name**.

-24. For **Surname**, use **family_name**.

-25. For **Emai**l, use **email**.

-26. Select **Save**.

-## SCreate a user flow policy

-1. In your Azure AD B2C tenant, under **Policies**, select **User flows**.

-2. Select **New user flow**.

-3. Select **Sign up and sign in** user flow type.

-4. Select **Version Recommended**.

-5. Select **Create**.

-6. Enter a user flow **Name**, such as `AsignioSignupSignin`.

-7. Under **Identity providers**, for **Local Accounts**, select **None**. This action disables email and password authentication.

-8. For **Custom identity providers**, select the created Asignio Identity provider.

-9. Select **Create**.

-## Test your user flow

-1. In your Azure AD B2C tenant, select **User flows**.

-2. Select the created user flow.

-3. For **Application**, select the web application you registered. The **Reply URL** is `https://jwt.ms`.

-4. Select **Run user flow**.

-5. The browser is redirected to the Asignio sign in page.

-6. A sign in screen appears.

-7. At the bottom, select **Asignio** authentication.

-If you have an Asignio Signature, complete the prompt to authenticate. If not, supply the device phone number to authenticate via SMS OTP. Use the link to register your Asignio Signature.

-8. The browser is redirected to `https://jwt.ms`. The token contents returned by Azure AD B2C appear.

-## Create Asignio policy key

-1. Store the generated Client Secret in the Azure AD B2C tenant.

-2. Sign in to the [Azure portal](https://portal.azure.com/).

-3. In the portal toolbar, select the **Directories + subscriptions**.

-4. On **Portal settings | Directories + subscriptions**, in the **Directory name** list, locate your Azure AD B2C directory.

-5. Select **Switch**.

-6. In the top-left corner of the Azure portal, select **All services**.

-7. Search for and select **Azure AD B2C**.

-8. On the Overview page, select **Identity Experience Framework**.

-9. Select **Policy Keys**.

-10. Select **Add**.

-11. For **Options**, select **Manual**.

-12. Enter a policy key **Name** for the policy key. The prefix `B2C_1A_` is appended to the key name.

-13. In **Secret**, enter the Client Secret that you noted.

-14. For **Key usage**, select **Signature**.

-15. Select **Create**.

-## Configure Asignio as an Identity provider

->[!TIP]

->Before you begin, ensure the Azure AD B2C policy is configured. If not, follow the instructions in [Custom policy starter pack](tutorial-create-user-flows.md?pivots=b2c-custom-policy#custom-policy-starter-pack).

-For users to sign in with Asignio, define Asignio as a claims provider that Azure AD B2C communicates with through an endpoint. The endpoint provides claims Azure AD B2C uses to verify user authentication with using digital ID on the device.

-### Add Asignio as a claims provider

-Get the custom policy starter packs from GitHub, then update the XML files in the LocalAccounts starter pack with your Azure AD B2C tenant name:

-1. Download the zip [active-directory-b2c-custom-policy-starterpack](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/archive/master.zip) or clone the repository:

- ```

- git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack

- ```

-

-2. In the files in the **LocalAccounts** directory, replace the string `yourtenant` with the Azure AD B2C tenant name.

-3. Open the **LocalAccounts/ TrustFrameworkExtensions.xml**.

-4. Find the **ClaimsProviders** element. If there isn't one, add it under the root element, `TrustFrameworkPolicy`.

-5. Add a new **ClaimsProvider** similar to the following example:

- ```xml

- <ClaimsProvider>

- <Domain>contoso.com</Domain>

- <DisplayName>Asignio</DisplayName>

- <TechnicalProfiles>

- <TechnicalProfile Id="Asignio-Oauth2">

- <DisplayName>Asignio</DisplayName>

- <Description>Login with your Asignio account</Description>

- <Protocol Name="OAuth2" />

- <Metadata>

- <Item Key="ProviderName">authorization.asignio.com</Item>

- <Item Key="authorization_endpoint">https://authorization.asignio.com/authorize</Item>

- <Item Key="AccessTokenEndpoint">https://authorization.asignio.com/token</Item>

- <Item Key="ClaimsEndpoint">https://authorization.asignio.com/userinfo</Item>

- <Item Key="ClaimsEndpointAccessTokenName">access_token</Item>

- <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>

- <Item Key="HttpBinding">POST</Item>

- <Item Key="scope">openid profile email</Item>

- <Item Key="UsePolicyInRedirectUri">0</Item>

- <!-- Update the Client ID below to the Asignio Application ID -->

- <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>

- <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>

- <!-- trying to add additional claim-->

- <!--Insert b2c-extensions-app application ID here, for example: 11111111-1111-1111-1111-111111111111-->

- <Item Key="11111111-1111-1111-1111-111111111111"></Item>

- <!--Insert b2c-extensions-app application ObjectId here, for example: 22222222-2222-2222-2222-222222222222-->

- <Item Key="22222222-2222-2222-2222-222222222222"></Item>

- <!-- The key below allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs below for each tenant. -->

- <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111</Item>-->

- <!-- The commented key below specifies that users from any tenant can sign-in. Uncomment if you would like anyone with an Azure AD account to be able to sign in. -->

- <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>

- </Metadata>

- <CryptographicKeys>

- <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />

- </CryptographicKeys>

- <OutputClaims>

- <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />

- <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />

- <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />

- <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" DefaultValue="https://authorization.asignio.com" />

- <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />

- <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />

- <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />

- <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />

- <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />

- </OutputClaims>

- <OutputClaimsTransformations>

- <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />

- <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />

- <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />

- <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />

- </OutputClaimsTransformations>

- <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />

- </TechnicalProfile>

- </TechnicalProfiles>

- </ClaimsProvider>

- ```

-6. Set **client_id** with the Asignio Application ID you noted.

-7. Update **client_secret** section with the policy key you created. For example, `B2C_1A_AsignioSecret`:

- ```xml

- <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />

- ```

-8. Save the changes.

-## Add a user journey

-The identity provider isn't in the sign in pages.

-1. If you have a custom user journey continue to **Configure the relying party policy**, otherwise, copy a template user journey:

-2. From the starter pack, open the **LocalAccounts/ TrustFrameworkBase.xml**.

-3. Locate and copy the contents of the **UserJourney** element that include `Id=SignUpOrSignIn`.

-4. Open the **LocalAccounts/ TrustFrameworkExtensions.xml**.

-5. Locate the **UserJourneys** element. If there isn't one, add one.

-6. Paste the UserJourney element contents as a child of the UserJourneys element.]

-7. Rename the user journey **ID**. For example, `Id=AsignioSUSI`.

-Learn more: [User journeys](custom-policy-overview.md#user-journeys)

-## Add the identity provider to a user journey

-Add the new identity provider to the user journey.

-1. Find the orchestration step element that includes `Type=CombinedSignInAndSignUp`, or `Type=ClaimsProviderSelection` in the user journey. It's usually the first orchestration step. The **ClaimsProviderSelections** element has an identity provider list that users sign in with. The order of the elements controls the order of the sign in buttons.

-2. Add a **ClaimsProviderSelection** XML element.

-3. Set the value of **TargetClaimsExchangeId** to a friendly name.

-4. Add a **ClaimsExchange** element.

-5. Set the **Id** to the value of the target claims exchange ID.

-6. Update the value of **TechnicalProfileReferenceId** to the ID of the technical profile you created.

-The following XML demonstrates user journey orchestration with the identity provider.

-```xml

- <UserJourney Id="AsignioSUSI">

- <OrchestrationSteps>

- <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">

- <ClaimsProviderSelections>

- <ClaimsProviderSelection TargetClaimsExchangeId="AsignioExchange" />

- <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />

- </ClaimsProviderSelections>

- <ClaimsExchanges>

- <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />

- </ClaimsExchanges>

- </OrchestrationStep>

- <!-- Check if the user has selected to sign in using one of the social providers -->

- <OrchestrationStep Order="2" Type="ClaimsExchange">

- <Preconditions>

- <Precondition Type="ClaimsExist" ExecuteActionsIf="true">

- <Value>objectId</Value>

- <Action>SkipThisOrchestrationStep</Action>

- </Precondition>

- </Preconditions>

- <ClaimsExchanges>

- <ClaimsExchange Id="AsignioExchange" TechnicalProfileReferenceId="Asignio-Oauth2" />

- <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />

- </ClaimsExchanges>

- </OrchestrationStep>

- <OrchestrationStep Order="3" Type="ClaimsExchange">

- <Preconditions>

- <Precondition Type="ClaimEquals" ExecuteActionsIf="true">

- <Value>authenticationSource</Value>

- <Value>localAccountAuthentication</Value>

- <Action>SkipThisOrchestrationStep</Action>

- </Precondition>

- </Preconditions>

- <ClaimsExchanges>

- <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />

- </ClaimsExchanges>

- </OrchestrationStep>

- <!-- Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId). This can only happen when authentication happened using a social IDP. If local account was created or authentication done using ESTS in step 2, then an user account must exist in the directory by this time. -->

- <OrchestrationStep Order="4" Type="ClaimsExchange">

- <Preconditions>

- <Precondition Type="ClaimsExist" ExecuteActionsIf="true">

- <Value>objectId</Value>

- <Action>SkipThisOrchestrationStep</Action>

- </Precondition>

- </Preconditions>

- <ClaimsExchanges>

- <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />

- </ClaimsExchanges>

- </OrchestrationStep>

- <!-- This step reads any user attributes that we may not have received when authenticating using ESTS so they can be sent in the token. -->

- <OrchestrationStep Order="5" Type="ClaimsExchange">

- <Preconditions>

- <Precondition Type="ClaimEquals" ExecuteActionsIf="true">

- <Value>authenticationSource</Value>

- <Value>socialIdpAuthentication</Value>

- <Action>SkipThisOrchestrationStep</Action>

- </Precondition>

- </Preconditions>

- <ClaimsExchanges>

- <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />

- </ClaimsExchanges>

- </OrchestrationStep>

- <!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect from the user. So, in that case, create the user in the directory if one does not already exist (verified using objectId which would be set from the last step if account was created in the directory. -->

- <OrchestrationStep Order="6" Type="ClaimsExchange">

- <Preconditions>

- <Precondition Type="ClaimsExist" ExecuteActionsIf="true">

- <Value>objectId</Value>

- <Action>SkipThisOrchestrationStep</Action>

- </Precondition>

- </Preconditions>

- <ClaimsExchanges>

- <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />

- </ClaimsExchanges>

- </OrchestrationStep>

- <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />

- </OrchestrationSteps>

- <ClientDefinition ReferenceId="DefaultWeb" />

- </UserJourney>

-```

-## Configure the relying party policy

-The relying party policy, for example [SignUpSignIn.xml](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/main/LocalAccounts/SignUpOrSignin.xml), specifies the user journey Azure AD B2C executes.

-1. In the relying party, locate the **DefaultUserJourney** element.

-2. Update the **ReferenceId** to match the user journey ID, in which you added the identity provider.

-In the following example, for the `AsignioSUSI` user journey, the **ReferenceId** is set to `AsignioSUSI`:

-```xml

- <RelyingParty>

- <DefaultUserJourney ReferenceId="AsignioSUSI" />

- <TechnicalProfile Id="PolicyProfile">

- <DisplayName>PolicyProfile</DisplayName>

- <Protocol Name="OpenIdConnect" />

- <OutputClaims>

- <OutputClaim ClaimTypeReferenceId="displayName" />

- <OutputClaim ClaimTypeReferenceId="givenName" />

- <OutputClaim ClaimTypeReferenceId="surname" />

- <OutputClaim ClaimTypeReferenceId="email" />

- <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>

- <OutputClaim ClaimTypeReferenceId="identityProvider" />

- <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />

- <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />

- </OutputClaims>

- <SubjectNamingInfo ClaimType="sub" />

- </TechnicalProfile>

- </RelyingParty>

-```

-## Upload the custom policy

-1. Sign in to the [Azure portal](https://portal.azure.com/#home).

-2. In the portal toolbar, select the **Directories + subscriptions**.

-3. On **Portal settings | Directories + subscriptions**, in the **Directory name** list, locate your Azure AD B2C directory.

-4. Select **Switch**.

-5. In the Azure portal, search for and select **Azure AD B2C**.

-6. Under Policies, select **Identity Experience Framework**.

-7. Select **Upload Custom Policy**.

-8. Upload the two policy files you changed in the following order:

- * Extension policy, for example `TrustFrameworkExtensions.xml`

- * Relying party policy, such as `SignUpOrSignin.xml`

-## Test your custom policy

-1. In your Azure AD B2C tenant, and under **Policies**, select **Identity Experience Framework**.

-2. Under **Custom policies**, select **AsignioSUSI**.

-3. For **Application**, select the web application that you registered. The **Reply URL** is `https://jwt.ms`.

-4. Select **Run now**.

-5. The browser is redirected to the Asignio sign in page.

-6. A sign in screen appears.

-7. At the bottom, select **Asignio** authentication.

-If you have an Asignio Signature, you're prompted to authenticate with your Asignio Signature. If not, supply the device phone number to authenticate via SMS OTP. Use the link to register your Asignio Signature.

-8. The browser is redirected to `https://jwt.ms`. The token contents returned by Azure AD B2C appear.

-## Next steps

-* [Solutions and Training for Azure Active Directory B2C](solution-articles.md)

-* Ask questions on [Stackoverflow](https://stackoverflow.com/questions/tagged/azure-ad-b2c)

-* [Azure AD B2C Samples](https://stackoverflow.com/questions/tagged/azure-ad-b2c)

-* YouTube: [Identity Azure AD B2C Series](https://www.youtube.com/playlist?list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0)

-* [Azure AD B2C custom policy overview](custom-policy-overview.md)

-* [Tutorial: Create user flows and custom policies in Azure Active Directory B2C](tutorial-create-user-flows.md?pivots=b2c-custom-policy)

-#Customer intent: As a developer using Azure Active Directory B2C, I want to define a self-asserted technical profile with display claims and output claims, so that I can collect and validate user input and return the claims to the next orchestration step.

-* The fifth display claim makes a reference to the `phoneVerificationControl` display control, which collects and verifies a phone number.

-| setting.retryLimit | No | Controls the number of times a user can try to provide the data that is checked against a validation technical profile. For example, a user tries to sign-up with an account that already exists and keeps trying until the limit reached. Check out the [Live demo](https://github.com/azure-ad-b2c/unit-tests/tree/main/technical-profiles/self-asserted#retry-limit) of this metadata.|

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

-| `additional_instructions` | string or null | Optional | Appends additional instructions at the end of the instructions for the run. This is useful for modifying the behavior on a per-run basis without overriding other instructions. |

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

-POST https://YOUR_RESOURCE_NAME.openai.azure.com/openai/threads{thread_id}?api-version=2024-02-15-preview

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

-DELETE https://YOUR_RESOURCE_NAME.openai.azure.com/openai/threads{thread_id}?api-version=2024-02-15-preview

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

-openai.api_key = os.getenv("AZURE_OPENAI_KEY")

-openai.api_key = os.getenv("AZURE_OPENAI_KEY")

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key = $Env:AZURE_OPENAI_KEY

-The third generation embeddings models support reducing the size of the embedding via a new `dimensions` parameter. Typically larger embeddings are more expensive from a compute, memory, and storage perspective. Being able to adjust the number of dimensions allows more control over overall cost and performance. Official support for the dimensions parameter was added to the OpenAI Python library in version `1.10.0`. If you are running an earlier version of the 1.x library you will need to upgrade `pip install openai --upgrade`.

-| gpt-4 (vision-preview) | Sweden Central <br> West US <br> Japan East| Switzerland North <br> Australia East |

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key = os.getenv("AZURE_OPENAI_KEY"),

- api_key = $Env:AZURE_OPENAI_KEY

-A fine-tuned model improves on the few-shot learning approach by training the model's weights on your own data. A customized model lets you achieve better results on a wider number of tasks without needing to provide examples in your prompt. The result is less text sent and fewer tokens processed on every API call, potentially saving cost and improving request latency.

-

- api_key=os.getenv("AZURE_OPENAI_KEY"),

-openai.api_key = os.getenv("AZURE_OPENAI_KEY")

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key = $Env:AZURE_OPENAI_KEY

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key = $Env:AZURE_OPENAI_KEY

-openai.api_key = os.getenv("AZURE_OPENAI_KEY")

- api_key=os.getenv("AZURE_OPENAI_KEY"),

-openai.api_key = os.getenv("AZURE_OPENAI_KEY")

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key = os.getenv("AZURE_OPENAI_KEY"),

- api_key = os.getenv("AZURE_OPENAI_KEY"),

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key = $Env:AZURE_OPENAI_KEY

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key = $Env:AZURE_OPENAI_KEY

- api_key=os.getenv("AZURE_OPENAI_KEY"),

-| Max file size for Assistants | 512 MB |

-<table>

- <tr>

- <th>Model</th>

- <th>Regions</th>

- <th>Tokens per minute</th>

- </tr>

- <tr>

- <td rowspan="2">gpt-35-turbo</td>

- <td>East US, South Central US, West Europe, France Central, UK South</td>

- <td>240 K</td>

- </tr>

- <tr>

- <td>North Central US, Australia East, East US 2, Canada East, Japan East, Sweden Central, Switzerland North</td>

- <td>300 K</td>

- </tr>

- <tr>

- <td rowspan="2">gpt-35-turbo-16k</td>

- <td>East US, South Central US, West Europe, France Central, UK South</td>

- <td>240 K</td>

- </tr>

- <tr>

- <td>North Central US, Australia East, East US 2, Canada East, Japan East, Sweden Central, Switzerland North</td>

- <td>300 K</td>

- </tr>

- <tr>

- <td>gpt-35-turbo-instruct</td>

- <td>East US, Sweden Central</td>

- <td>240 K</td>

- </tr>

- <tr>

- <td>gpt-35-turbo (1106)</td>

- <td> Australia East, Canada East, France Central, South India, Sweden Central, UK South, West US

-</td>

- <td>120 K</td>

- </tr>

- <tr>

- <td rowspan="2">gpt-4</td>

- <td>East US, South Central US, France Central</td>

- <td>20 K</td>

- </tr>

- <tr>

- <td>North Central US, Australia East, East US 2, Canada East, Japan East, UK South, Sweden Central, Switzerland North</td>

- <td>40 K</td>

- </tr>

- <tr>

- <td rowspan="2">gpt-4-32k</td>

- <td>East US, South Central US, France Central</td>

- <td>60 K</td>

- </tr>

- <tr>

- <td>North Central US, Australia East, East US 2, Canada East, Japan East, UK South, Sweden Central, Switzerland North</td>

- <td>80 K</td>

- </tr>

- <tr>

- <td rowspan="2">gpt-4 (1106-preview)<br>GPT-4 Turbo </td>

- <td>Australia East, Canada East, East US 2, France Central, UK South, West US</td>

- <td>80 K</td>

- </tr>

- <tr>

- <td>South India, Norway East, Sweden Central</td>

- <td>150 K</td>

- </tr>

-<tr>

- <td>gpt-4 (vision-preview)<br>GPT-4 Turbo with Vision</td>

- <td>Sweden Central, Switzerland North, Australia East, West US</td>

- <td>30 K</td>

- </tr>

- <tr>

- <td rowspan="2">text-embedding-ada-002</td>

- <td>East US, South Central US, West Europe, France Central</td>

- <td>240 K</td>

- </tr>

- <tr>

- <td>North Central US, Australia East, East US 2, Canada East, Japan East, UK South, Switzerland North</td>

- <td>350 K</td>

- </tr>

-<tr>

- <td>Fine-tuning models (babbage-002, davinci-002, gpt-35-turbo-0613)</td>

- <td>North Central US, Sweden Central</td>

- <td>50 K</td>

- </tr>

- <tr>

- <td>all other models</td>

- <td>East US, South Central US, West Europe, France Central</td>

- <td>120 K</td>

- </tr>

-</table>

-| `AZURE_OPENAI_KEY` | This value can be found in the **Keys & Endpoint** section when examining your resource from the Azure portal. You can use either `KEY1` or `KEY2`.|

-setx AZURE_OPENAI_KEY "REPLACE_WITH_YOUR_KEY_VALUE_HERE"

-[System.Environment]::SetEnvironmentVariable('AZURE_OPENAI_KEY', 'REPLACE_WITH_YOUR_KEY_VALUE_HERE', 'User')

-echo export AZURE_OPENAI_KEY="REPLACE_WITH_YOUR_KEY_VALUE_HERE" >> /etc/environment && source /etc/environment

- api_key=os.getenv("AZURE_OPENAI_KEY"),

-print("Status:", response.id)

-openai.api_key = os.getenv("AZURE_OPENAI_KEY")

- api_key=os.getenv("AZURE_OPENAI_KEY"),

-| `AZURE_OPENAI_KEY` | This value can be found in the **Keys & Endpoint** section when examining your resource from the Azure portal. You can use either `KEY1` or `KEY2`.|

-setx AZURE_OPENAI_KEY "REPLACE_WITH_YOUR_KEY_VALUE_HERE"

-[System.Environment]::SetEnvironmentVariable('AZURE_OPENAI_KEY', 'REPLACE_WITH_YOUR_KEY_VALUE_HERE', 'User')

-echo export AZURE_OPENAI_KEY="REPLACE_WITH_YOUR_KEY_VALUE_HERE" >> /etc/environment && source /etc/environment

-Connections can be set up as shared with all projects in the same Azure AI hub resource, or created exclusively for one project. To manage project connections via Azure AI Studio, navigate to a project page, then navigate to **Settings** > **Connections**. To manage shared connections, navigate to the **Manage** page. As an administrator, you can audit both shared and project-scoped connections on an Azure AI hub resource level to have a single pane of glass of connectivity across projects.

-1. In [Azure AI Studio](https://ai.azure.com), go to **Build** > **Settings** to view your Azure AI project resources such as connections and API keys. There's a link to your Azure AI hub resource in Azure AI Studio and links to view the corresponding project resources in the [Azure portal](https://portal.azure.com).

-description: This article introduces connections in Azure AI Studio

-Connections in Azure AI Studio are a way to authenticate and consume both Microsoft and third-party resources within your Azure AI projects. For example, connections can be used for prompt flow, training data, and deployments. [Connections can be created](../how-to/connections-add.md) exclusively for one project or shared with all projects in the same Azure AI hub resource.

-## Connections to third-party services

-Azure AI Studio supports connections to third-party services, including the following:

-A Uniform Resource Identifier (URI) represents a storage location on your local computer, Azure storage, or a publicly available http(s) location. These examples show URIs for different storage options:

-|Storage location | URI examples |

-|||

-|Azure AI Studio connection | `azureml://datastores/<data_store_name>/paths/<folder1>/<folder2>/<folder3>/<file>.parquet` |

-|Local files | `./home/username/data/my_data` |

-|Public http(s) server | `https://raw.githubusercontent.com/pandas-dev/pandas/main/doc/data/titanic.csv` |

-|Blob storage | `wasbs://<containername>@<accountname>.blob.core.windows.net/<folder>/`|

-|Azure Data Lake (gen2) | `abfss://<file_system>@<account_name>.dfs.core.windows.net/<folder>/<file>.csv` |

-|Microsoft OneLake | `abfss://<file_system>@<account_name>.dfs.core.windows.net/<folder>/<file>.csv` `https://<accountname>.dfs.fabric.microsoft.com/<artifactname>` |

-Azure connections serve as key vault proxies, and interactions with connections are direct interactions with an Azure key vault. Azure AI Studio connections store API keys securely, as secrets, in a key vault. The key vault [Azure role-based access control (Azure RBAC)](./rbac-ai-studio.md) controls access to these connection resources. A connection references the credentials from the key vault storage location for further use. You won't need to directly deal with the credentials after they are stored in the Azure AI hub resource's key vault. You have the option to store the credentials in the YAML file. A CLI command or SDK can override them. We recommend that you avoid credential storage in a YAML file, because a security breach could lead to a credential leak.

-For any model deployment in Azure AI Studio, you could directly use the default content filter, but when you want to have more customized setting on content filter, for example set a stricter or looser filter, or enable more advanced capabilities, like jailbreak risk detection and protected material detection. To create a content filter, you could go to **Build**, choose one of your projects, then select **Content filters** in the left navigation bar, and create a content filter.

-### More filters for Gen-AI scenarios

-You could also enable filters for Gen-AI scenarios: jailbreak risk detection and protected material detection.

-1. Select **Settings** from the collapsible left menu.

-1. Select your project and then select **Settings** from the left navigation menu.

-1. On the collapsible left menu, select **Settings**.

-In the project details page (select **Build** > **Settings**), you can find information about the project, such as the project name, description, and the Azure AI hub resource that hosts the project. You can also find the project ID, which is used to identify the project in the Azure AI Studio API.

-If you're using SDK or CLI to create data, you must specify a `path` that points to the data location. Supported paths include:

-The Azure AI Studio's evaluation page is a versatile hub that not only allows you to visualize and assess your results but also serves as a control center for optimizing, troubleshooting, and selecting the ideal AI model for your deployment needs. It's a one-stop solution for data-driven decision-making and performance enhancement in your AI projects. You can seamlessly access and interpret the results from various sources, including your flow, the playground quick test session, evaluation submission UI, generative SDK and CLI. This flexibility ensures that you can interact with your results in a way that best suits your workflow and preferences.

-Upon submitting your evaluation, you can locate the submitted evaluation run within the run list by navigating to the 'Evaluation' tab.

-You can oversee your evaluation runs within the run list. With the flexibility to modify the columns using the column editor and implement filters, you can customize and create your own version of the run list. Additionally, you have the ability to swiftly review the aggregated evaluation metrics across the runs, enabling you to perform quick comparisons.

-1. Select **Settings** > **Resource providers** from the left menu.

-1. Select **Settings** from the collapsible left menu.

-1. Select **Settings** from the collapsible left menu.

-By default, operational metrics such as requests per minute and request latency show up. The default safety and quality monitoring signal are configured with a 10% sample rate and run on your default workspace Azure Open AI connection.

-1. Go to **Settings** > **Connections**.

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Go to **Settings** > **Connections**.

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-Prompt flow is available independently as an open-source project on [GitHub](https://github.com/microsoft/promptflow), with its own SDK and [VS Code extension](https://marketplace.visualstudio.com/items?itemName=prompt-flow.prompt-flow). Prompt flow is also available and recommended to use as a feature within both [Azure AI Studio](https://aka.ms/AzureAIStudio) and [Azure Machine Learning studio](https://aka.ms/AzureAIStudio). This set of documentation focuses on prompt flow in Azure AI Studio.

-`max_tokens` and `temperature` are optional, the default value for `max_tokens` is 300, the default value for `temperature` is 0.9

-1. Go to your project and select **Settings** from the left menu.

-2. Select your Azure AI hub resource name under **Resource configurations** on the **Settings** page.

-1. Select **Generate product name ideas** from the **Examples** dropdown menu. The system prompt is prepopulated with something resembling the following text:

-1. Select `Generate`. Azure OpenAI generates product name ideas based on. You should get a result that resembles the following list:

-You can still use the Azure AI Studio (that's still open in another browser tab) while working in VS Code Web. You can see the compute is running via **Build** > **Settings** > **Compute instances**. You can pause or stop the compute from here.

-Within **Explore**, you can [explore many capabilities](../how-to/models-foundation-azure-ai.md) found within the secondary navigation. These include [model catalog](../how-to/model-catalog.md), model leaderboard, and pages for Azure AI services such as Speech, Vision, and Content Safety.

-1. Press the **Tab** key until you hear *New project* and select this button.

-The chat session pane is where you can chat to the model and test out your assistant

- ```

- [message from user] [user image]

- [chatbot image] [message from chatbot]

- ```

-Prompt flow is a tool to create executable flows, linking LLMs, prompts and Python tools through a visualized graph. You can use this to prototype, experiment and iterate on your AI applications before deploying.

-With the Build tab selected, navigate to the secondary navigation landmark and press the down arrow until you hear *flows*.

-The prompt flow UI in Azure AI Studio is composed of the following main sections: Command toolbar, Flow (includes list of the flow nodes), Files and the Graph view. The Flow, Files and Graph sections each have their own H2 headings that can be used for navigation.

-Evaluation is a tool to help you evaluate the performance of your generative AI application. You can use this to prototype, experiment and iterate on your applications before deploying.

-1. Navigate to the secondary navigation landmark and press the down arrow until you hear *evaluations*.

-You might prefer to export the data from your evaluation run so that you can view it in an application of your choosing. To do this, select your evaluation run link, then navigate to the **Export results** button and select it.

-There's also a dashboard view provided to allow you to compare evaluation runs. From the main Evaluations list page, navigate to the **Switch to dashboard view** button. You can also export all this data using the **Export table** button.

-This step is also a good time to review the [inbound and outbound network](networking.md#ports-and-network-restrictions) dependency changes in moving to App Service Environment v3. These changes include the port change for Azure Load Balancer, which now uses port 80. Don't move to the next step until you confirm that you made these updates.

-> In rare cases, you might see a notification in the portal that says "Migration to App Service Environment v3 failed" after you start the migration. There's a known bug that might trigger this notification even if the migration is progressing. Check the activity log for the App Service Environment to determine the validity of this error message.

-> :::image type="content" source="./media/migration/migration-error.png" alt-text="Screenshot that shows the potential error notification after migration starts.":::

-This step is your opportunity to test and validate your new App Service Environment v3. Once you confirm your apps are working as expected, you can redirect customer traffic to your new environment by running the following command. This command also deletes your old environment.

-|Your InteralLoadBalancingMode is not currently supported.|App Service Environments that have InternalLoadBalancingMode set to certain values can't be migrated using the migration feature at this time. |Migrate using one of the [manual migration options](migration-alternatives.md) if you want to migrate immediately. |

-|Your InternalLoadBalancingMode is not currently supported.|App Service Environments that have InternalLoadBalancingMode set to certain values can't be migrated using the side by side migration feature at this time. |Migrate using one of the [manual migration options](migration-alternatives.md) if you want to migrate immediately. |

-The final step is to redirect traffic to your new App Service Environment v3 and complete the migration. The platform does this change for you, but only when you initiate it. Before you do this step, you should review your new App Service Environment v3 and perform any needed testing to validate that it's functioning as intended. You can do this review using the IPs associated with your App Service Environment v3 from the IP generation steps. Once you're ready to redirect traffic, you can complete the final step of the migration. This step updates internal DNS records to point to the load balancer IP address of your new App Service Environment v3. Changes are effective immediately. This step also shuts down your old App Service Environment and deletes it. Your new App Service Environment v3 is now your production environment.

-Azure [Confidential VM](../confidential-computing/confidential-vm-overview.md) (CVM) is based on [AMD processors with SEV-SNP technology](../confidential-computing/virtual-machine-solutions.md). CVM offers VM OS disk encryption option with platform-managed keys or customer-managed keys and binds the disk encryption keys to the virtual machine's TPM. When a CVM boots up, SNP report containing the guest VM firmware measurements is sent to Azure Attestation. The service validates the measurements and issues an attestation token that is used to release keys from [Managed-HSM](../key-vault/managed-hsm/overview.md) or [Azure Key Vault](../key-vault/general/basic-concepts.md). These keys are used to decrypt the vTPM state of the guest VM, unlock the OS disk and start the CVM. The attestation and key release process is performed automatically on each CVM boot, and the process ensures the CVM boots up only upon successful attestation of the hardware.

-[Create an Azure Arc VM](create-virtual-machine.md)

-This Quickstart shows you how to connect your SCVMM management server to Azure Arc using a helper script. The script deploys a lightweight Azure Arc appliance (called Azure Arc resource bridge) as a virtual machine running in your VMM environment and installs an SCVMM cluster extension on it, to provide a continuous connection between your VMM management server and Azure Arc.

-1. Open the terminal and navigate to the folder, where you've downloaded the Bash script.

-| **Private cloud selection** | Select the name of the private cloud where the Arc resource bridge VM should be deployed. |

-8. Under **Region**, select an Azure location where the resource metadata will be stored. Currently, supported regions are **East US**, **West Europe**, **Australia East** and **Canada Central**.

-| **Static IP / DHCP** | For deploying Azure Arc resource bridge, the preferred configuration is to use Static IP. Enter **n** to select static IP configuration. While not recommended, if you have DHCP server in your network and want to use it instead, enter **y**. If you're using a DHCP server, reserve the IP address assigned to the Azure Arc Resource Bridge VM (Appliance VM IP). If you use DHCP, the cluster configuration IP address still needs to be a static IP address. </br>When you choose a static IP configuration, you're asked for the following information: </br> 1. **Static IP address prefix**: Network address in CIDR notation. For example: **192.168.0.0/24**. </br> 2. **Static gateway**: Gateway address. For example: **192.168.0.0**. </br> 3. **DNS servers**: IP address(es) of DNS server(s) used by Azure Arc resource bridge VM for DNS resolution. Azure Arc resource bridge VM must be able to resolve external sites, like mcr.microsoft.com and the vCenter server. </br> 4. **Start range IP**: Minimum size of two available IP addresses is required. One IP address is for the Azure Arc resource bridge VM, and the other is reserved for upgrade scenarios. Provide the starting IP address of that range. Ensure the Start range IP has internet access. </br> 5. **End range IP**: Last IP address of the IP range requested in the previous field. Ensure the End range IP has internet access. </br>|

-| **Control Plane IP address** | Azure Arc resource bridge runs a Kubernetes cluster, and its control plane always requires a static IP address. Provide an IP address that meets the following requirements: <br> - The IP address must have internet access. <br> - The IP address must be within the subnet defined by IP address prefix. <br> - If you're using static IP address option for resource bridge VM IP address, the control plane IP address must be outside of the IP address range provided for the VM (Start range IP - End range IP). <br> - If there's a DHCP service on the network, the IP address must be outside of DHCP range.|

-| **VM template Name** | Provide a name for the VM template that will be created in your vCenter Server instance based on the downloaded OVA file. For example: **arc-appliance-template**. |

-[Azure Active Directory authentication]: azure-maps-authentication.md#azure-ad-authentication

-[Azure Active Directory authentication]: azure-maps-authentication.md#azure-ad-authentication

-[Implement dynamic styling for Creator  indoor maps]: indoor-map-dynamic-styling.md

-<center></center>

-<center>

-</center>

-There's usually no difference, with a couple of exceptions:

-We strongly encourage updating to the [new API](https://learn.microsoft.com/azure/azure-monitor/app/resource-manager-app-resource) for better control over resource creation.

-* Python 3.7 or later installed. To install the latest, see [Python.org](https://www.python.org/downloads/)

->**Azure VMware Solution private cloud (source) > ExpressRoute gateway (source) > ExpressRoute gateway (target) > Azure VMware Solution private cloud (target)**

-

- You can have up to eight VLANs per appliance, but you can deploy another appliance to add another eight VLANs. You must also have IP space to account for the more appliances, and it's one IP per appliance. For more information, see [VMware HCX Configuration Limits](https://configmax.vmware.com/guest?vmwareproduct=VMware%20HCX&release=VMware%20HCX&categories=41-0,42-0,43-0,44-0,45-0).

-3. Use VMware HCX to migrate all VM templates from the source's vCenter Server to the target's vCenter.

-In this step, use the source NSX-T Data Center configuration to configure the target NSX-T environment.

->You'll have multiple features configured on the source NSX-T Data Center, so you must copy or read from the source NSX-T Data Center and recreate it in the target private cloud. Use L2 Extension to keep same IP address and Mac Address of the VM while migrating Source to target AVS Private Cloud to avoid downtime due to IP change and related configuration.

-> [Tutorial: Add a custom domain to your Azure CDN endpoint](cdn-map-content-to-custom-domain.md)

-description: An explanation of legacy devices on the Azure Certified Device catalog

-# Legacy devices on the Azure Certified Device catalog

-You may have noticed on the Azure Certified Device catalog that some devices don't have the blue outline or the "Azure Certified Device" label. These devices (dubbed "legacy devices") were previously certified under the legacy program.

-## Certified for Azure IoT program

-Before the launch of the Azure Certified Device program, hardware partners could previously certify their products under the Certified for Azure IoT program. The Azure Certified Device certification program refocuses its mission to deliver on customer promises rather than technical device capabilities.

-Devices that have been certified as an ΓÇÿIoT Hub certified deviceΓÇÖ appear on the Azure Certified Device catalog as a ΓÇÿlegacy device.ΓÇÖ This label indicates devices have previously qualified through the now-retired program, but haven't been certified through the updated Azure Certified Device program. These devices are clearly noted in the catalog by their lack of blue outline, and can be found through the "IoT Hub Certified devices (legacy)" filter.

-## Next steps

-Interested in recertifying a legacy device under the Azure Certified Device program? You can submit your device through our portal and leave a note to our review team to coordinate. Follow the link below to get started!

-description: A description of the different marketing fields collected in the portal and how they will appear on the Azure Certified Device catalog

-# Marketing properties

-In the process of [adding your device details](tutorial-02-adding-device-details.md), you will be required to supply marketing information that will be displayed on the [Azure Certified Device catalog](https://devicecatalog.azure.com). This information is collected within the Azure Certified Device portal during the certification submission process and will be used as filter parameters on the catalog. This article provides a mapping between the fields collected in the portal to how they appear on the catalog. After reading this article, partners should better understand what information to provide during the certification process to best represent their product on the catalog.

-

-## Azure Certified Device catalog product tile

-Visitors to the catalog will first interact with your device as a catalog product tile on the search page. This will provide a basic overview of the device and certifications it has been awarded.

-

-| Field | Description | Where to add in the portal |

-||-|-|

-| Device Name | Public name of your certified device | Basics tab of Device details|

-| Company name| Public name of your company | Not editable in the portal. Extracted from MPN account name |

-| Product photo | Image of your device with minimum resolution 200p x 200p | Marketing details |

-| Certification classification | Mandatory Azure Certified Device certification label and optional certification badges | Basics tab of Device details. Must pass appropriate testing in Connect & test section. |

-## Product description page information

-Once a customer has clicked on your device tile from the catalog search page, they will be navigated to the product description page of your device. This is where the bulk of the information provided during the certification process will be found.

-The top of the product description page highlights key characteristics, some of which were already used for the product tile.

-

-| Field | Description | Where to add in the portal |

-||-|-|

-| Device class | Classification of the form factor and primary purpose of your device ([Learn more](./resources-glossary.md)) | Basics tab of Device details|

-| Device type | Classification of device based on implementation readiness ([Learn more](./resources-glossary.md)) | Basics tab of Device details |

-| Geo availability | Regions that your device is available for purchase | Marketing details |

-| Operating systems | Operating system(s) that your device supports | Product details tab of Device details |

-| Target industries | Top 3 industries that your device is optimized for | Marketing details |

-| Product description | Free text field for you to write your marketing description of your product. This can capture details not listed in the portal, or add additional context for the benefits of using your device. | Marketing details|

-The remainder of the page is focused on displaying the technical specifications of your device in table format that will help your customer better understand your product. For convenience, the information displayed at the top of the page is also listed here, along with some additional device information. The rest of the table is sectioned by the components specified in the portal.

-

-| Field | Description | Where to add in the portal |

-||-|-|

-| Environmental certifications | Official certifications received for performance in different environments | Hardware of Device details |

-| Operating conditions | Ingress Protection value or temperature ranges the device is qualified for | Software of device details |

-| Azure software set-up | Classification of the set-up process to connect the device to Azure ([Learn more](./how-to-software-levels.md)) | Software of Device details |

-| Component type | Classification of the form factor and primary purpose of your device ([Learn more](./resources-glossary.md)) | Hardware of Device details|

-| Component name| Name of the component you are describing | Product details of Device details |

-| Additional component information | Additional hardware specifications such as included sensors, connectivity, accelerators, etc. | Additional component information of Device details ([Learn more](./how-to-using-the-components-feature.md)) |

-| Device dependency text | Partner-provided text describing the different dependencies the product requires to connect to Azure ([Learn more](./how-to-indirectly-connected-devices.md)) | Customer-facing comments section of Dependencies tab of Device details |

-| Device dependency link | Link to a certified device that your current product requires | Dependencies tab of Device details |

-## Shop links

-Available both on the product tile and product description page is a Shop button. When clicked by the customer, a window opens that allows them to select a distributor (you are allowed to list up to 5 distributors). Once selected, the customer is redirected to the partner-provided URL.

-

-| Field | Description | Where to add in the portal |

-||-|-|

-| Distributor name | Name of the distributor who is selling your product | Marketing details|

-| Get Device| Link to external website for customer to purchase the device (or request a quote from the distributor). This may be the same as the Manufacturer's page if the distributor is the same as the device manufacturer. If a purchase page is not available, this will redirect to the distributor's page for customer to contact them directly. | Distributor product page URL in marketing details. If no purchase page is available, link will default to Distributor URL in Marketing detail. |

-## External links

-Also included within the Product Description page are links that navigate to partner-provided sites or files that help the customer better understand the product. They appear towards the top of the page, beneath the product description text. The links displayed will differ for different device types and certification programs.

-| Link | Description | Where to add in the portal |

-||-|-|

-| Get Started guide* | PDF file with user instructions to connect and use your device with Azure services | Add 'Get Started' guide section of the portal|

-| Manufacturer's page*|Link to manufacturer's page. This page may be the specific product page for your device, or to the company home page if a marketing page is not available. | Manufacturer's marketing page in Marketing details |

-| Device model | Public DTDL models for IoT Plug and Play solutions | Not editable in the portal. Device model must be uploaded to the ([public model repository](https://aka.ms/modelrepo) |

-| Device source code | URL to device source code for Dev Kit device types| Basics tab of Device details |

- **Required for all published devices*

-## Next steps

-Now that you have an understanding of how we use the information you provide during certification, you are now ready to certify your device! Begin your certification project, or jump back into the device details stage to add your own marketing information.

-description: A guide to edit you device information after you have certified and published your device through the Azure Certified Device program.

-# Edit your published device

-After your device has been certified and published to the Azure Certified Device catalog, you may need to update your device details. This may be due to an update to your distributor list, changes to purchase page URLs, or updates to the hardware specifications (such as operating system version or a new component addition). You may also have to update your IoT Plug and Play device model from what you originally uploaded to the model repository.

-## Prerequisites

-## Editing your published project information

-On the project summary, you should notice that your project is in read-only mode since it has already been reviewed and accepted. To make changes, you will have to request an edit to your project and have the update re-approved by the Azure Certification team.

-1. Click the `Request Metadata Edit` button on the top of the page

- 

-1. Acknowledge the notification on the page that you will be required to submit your product for review after editing.

- > [!NOTE]

- > By confirming this edit, you are **not** removing your device from the Azure Certified Device catalog if it has already been published. Your previous version of the product will remain on the catalog until you have republished your device.

- > You will also not have to repeat the Connect & test section of the portal.

-1. Once acknowledging this warning, you can edit your device details. Make sure to leave a note in the `Comments for Reviewer` section of `Device Details` of what has been changed.

- 

-1. On the project summary page, click `Submit for review` to have your changes reapproved by the Azure Certification team.

-1. After your changes have been reviewed and approved, you can then republish your changes to the catalog through the portal (See our [tutorial](./tutorial-04-publishing-your-device.md)).

-## Editing your IoT Plug and Play device model

-Once you have submitted your device model to the public model repository, it cannot be removed. If you update your device model and would like to re-link your certified device to the new model, you **must re-certify** your device as a new project. If you do this, please leave a note in the 'Comments for Reviewer' section so the certification team can remove your old device entry.

-## Next steps

-You've now successfully edited your device on the Azure Certified Device catalog. You can check out your changes on the catalog, or certify another device!

-# Mandatory fields.

-description: Learn how to submit a bundled or indirectly connected device for Azure Certified Device certification. See how to configure dependencies and components.

-# Optional fields. Don't forget to remove # if you need a field.

-#

-#

-# Device bundles and indirectly connected devices

-Many devices interact with Azure indirectly. Some communicate through another device, such as a gateway. Others connect through software as a service (SaaS) or platform as a service (PaaS) offerings.

-The [submission portal](https://certify.azure.com/) and [device catalog](https://devicecatalog.azure.com) offer support for indirectly connected devices:

-This functionality gives indirectly connected devices access to the Azure Certified Device program.

-Depending on your product line and the services that you offer or use, your situation might require a combination of dependencies and bundling. The Azure Edge Certification Portal provides a way for you to list dependencies and additional components.

-## Sensors and indirect devices

-Many sensors require a device to connect to Azure. In addition, you might have multiple compatible devices that work with the sensor. **To accommodate these scenarios, certify the devices before you certify the sensor that passes information through them.**

-The following matrix provides some examples of submission combinations:

-To certify a sensor that requires a separate device:

-1. Go to the [Azure Certified Device portal](https://certify.azure.com) to certify the device and publish it to the Azure Certified Device catalog. If you have multiple, compatible pass-through devices, as in the earlier example, submit them separately for certification and catalog publication.

-1. With the sensor connected through the device, submit the sensor for certification. In the **Dependencies** tab of the **Device details** section, set the following values:

- - **Dependency type**: Select **Hardware gateway**.

- - **Dependency URL**: Enter the URL of the device in the device catalog.

- - **Used during testing**: Select **Yes**.

- - **Customer-facing comments**: Enter any comments that you'd like to provide to a user who sees the product description in the device catalog. For example, you might enter **Series 100 devices are required for sensors to connect to Azure**.

-1. If you'd like to add more devices as optional for this device:

- 1. Select **Add additional dependency**.

- 1. Enter **Dependency type** and **Dependency URL** values.

- 1. For **Used during testing**, select **No**.

- 1. For **Customer-facing comments**, enter a comment that informs your customers that other devices are available as alternatives to the device that was used during testing.

-## PaaS and SaaS offerings

-As part of your product portfolio, you might certify a device that requires services from your company or third-party companies. To add this type of dependency:

-1. Go to the [Azure Certified Device portal](https://certify.azure.com) and start the submission process for your device.

-1. In the **Dependencies** tab, enter the following values:

- - **Dependency type**: Select **Software service**.

- - **Service name**: Enter the name of your product.

- - **Dependency URL**: Enter the URL of a product page that describes the service.

- - **Customer-facing comments**: Enter any comments that you'd like to provide to a user who sees the product description in the Azure Certified Device catalog.

-1. If you have other software, services, or hardware dependencies that you'd like to add as optional for this device, select **Add additional dependency** and enter the required information.

-## Bundled products

-With bundled product listings, a device is successfully certified in the Azure Certified Device program with other components. The device and the components are then sold together under one product listing.

-The following matrix provides some examples of bundled products. You can submit a device that includes extra components such as a temperature sensor and a camera sensor, as in submission example 1. You can also submit a touch sensor that includes a pass-through device, as in submission example 2.

-Use the component feature to add multiple components to your listing. Format the product listing image to indicate that your product comes with other components. If your bundle requires additional services for certification, identify those services through service dependencies.

-For a more detailed description of how to use the component functionality in the Azure Certified Device portal, see [Add components on the portal](./how-to-using-the-components-feature.md).

-If a device is a pass-through device with a separate sensor in the same product, create one component to reflect the pass-through device, and another component to reflect the sensor. As the following screenshot shows, you can add components to your project in the **Product details** tab of the **Device details** section:

-Configure the pass-through device first. For **Component type**, select **Customer Ready Product**. Enter the other values, as relevant for your product. The following screenshot provides an example:

-For the sensor, add a second component. For **Component type**, select **Peripheral**. For **Attachment method**, select **Discrete**. The following screenshot provides an example:

-After you've created the sensor component, enter its information. Then go to the **Sensors** tab and enter detailed sensor information, as the following screenshot shows.

-Complete the rest of your project's details, and then submit your device for certification as usual.

-description: A breakdown of the different software levels that an Azure Certified Device may be classified as.

-# Software levels of Azure Certified Devices

-Software levels are a feature defined by the Azure Certified Device program to help device builders indicate the technical level of difficulty a customer can expect when connecting the device to Azure services. Appearing on the catalog as "Azure software set-up," these values are aimed to help viewers better understand the product and its connection to Azure. The definitions of each of these levels are provided below.

-## Level 1

-User can immediately connect device to Azure by simply adding provisioning details. The certified IoT device already contains pre-installed software that was used for certification upon purchase. This level is most similar to having an "out-of-the-box" set-up experience for IoT beginners who are not as comfortable with compiling source code.

-## Level 2

-User must flash/apply manufacturer-provided software image to the device to connect to Azure. Extra tools/software experience may be required. The link to the software image is also provided in our catalog.

-## Level 3

-User must follow a manufacturer-provided guide to prepare and install Azure-specific software. No Azure-specific software image is provided, so some customization and compilation of provided source code is required.

-## Level 4

-User must develop, customize, and recompile their own device code to connect to Azure. No manufacturer-supported source code is available. This level is most well suited for developers looking to create custom deployments for their device.

-## Next steps

-These levels are aimed to help you get started with building IoT solutions with Azure! Ready to get started? Visit the [Azure Certified Device catalog](https://devicecatalog.azure.com) to get searching for devices!

-Are you a device builder who is looking to add this software level to your certified device? Check out the links below.

-description: A guide describing how to test Device Update for IoT Hub on a Linux host in preparation for Edge Secured-core certification.

-# How to test Device Update for IoT Hub

-The [Device Update for IoT Hub](..\iot-hub-device-update\understand-device-update.md) test exercises your deviceΓÇÖs ability to receive an update from IoT Hub. The following steps will guide you through the process to test Device Update for IoT Hub when attempting device certification.

-## Prerequisites

-* Device must be capable of running Linux [IoT Edge supported container](..\iot-edge\support.md).

-* Your device must be capable of receiving an [.SWU update](https://swupdate.org/) and be able to return to a running and connected state after the update is applied.

-* The update package and manifest must be applicable to the device under test. (Example: If the device is running ΓÇ£Version 1.0ΓÇ¥, the update should be ΓÇ£Version 2.0ΓÇ¥.)

-* Upload your .SWU file to a blob storage location of your choice.

-* Create a SAS URL for accessing the uploaded .SWU file.

-## Test the device

-1. On the Connect + test page, select **"Yes"** for the **"Are you able to test Device Update for IoT Hub?"** question.

- > [!Note]

- > If you are not able to test Device Update and select No, you will still be able to run all other Secured-core tests, but your product will not be eligible for certification.

- :::image type="content" source="./media/how-to-adu/connect-test.png" alt-text="Dialog to confirm that you are able to test device for IoT Hub.":::

-2. Proceed with connecting your device to the test infrastructure.

-3. On the Select Requirement Validation step, select **"Upload"**.

- :::image type="content" source="./media/how-to-adu/connect-and-test.png" alt-text="Dialog that shows the selected tests that will be validated.":::

-4. Upload your .importmanifest.json file by selecting the **Choose File** button. Select your file and then select the **Upload** button.

- > [!Note]

- > The file extension must be .importmanifest.json.

-

- :::image type="content" source="./media/how-to-adu/upload-manifest.png" alt-text="Dialog to instruct the user to upload the .importmanifest.json file by selecting the choose File button.":::

-5. Copy and Paste the SAS URL to the location of your .SWU file in the provided input box, then select the **Validate** button.

- :::image type="content" source="./media/how-to-adu/input-sas-url.png" alt-text="Dialog that shows how the SAS url is applied.":::

-6. Once weΓÇÖve validated our service can reach the provided URL, select **Import**.

- :::image type="content" source="./media/how-to-adu/finalize-import.png" alt-text="Dialog to inform the user that the SAS URL was reachable and that the user needs to click import.":::

- > [!Note]

- > If you receive an ΓÇ£Invalid SAS URLΓÇ¥ message, generate a new SAS URL from your storage blob and try again.

-7. Select **Continue** to proceed

-8. Congratulations! You're now ready to proceed with Edge Secured-core testing.

-9. Select the **Run tests** button to begin the testing process. Your device will be updated as the final step in our Edge Secured-core testing.

-description: A guide on how to best use the components feature of the Device details section to accurately describe your device

-# Add components on the portal

-While completing the [tutorial to add device details](tutorial-02-adding-device-details.md) to your certification project, you will be expected to describe the hardware specifications of your device. To do so, users can highlight multiple, separate hardware products (referred to as **components**) that make up your device. This enables you to better promote devices that come with additional hardware, and allows customers to find the right product by searching on the catalog based on these features.

-## Prerequisites

-## How to add components

-Every project submitted for certification will include one **Customer Ready Product** component (which in many cases will represent the holistic product itself). To better understand the distinction of a Customer Ready Product component type, view our [certification glossary](./resources-glossary.md). All additional components are at your discretion to include to accurately capture your device.

-1. Select `Add a component` on the Hardware tab.

- 

-1. Complete relevant form fields for the component.

- 

-1. Save your information using the `Save Product Details` button at the bottom of the page:

- 

-1. Once you have saved your component, you can further tailor the hardware capabilities it supports. Select the `Edit` link by the component name.

- 

-1. Provide relevant hardware capability information where appropriate.

- 

- The editable component fields (shown above) include:

- - **General**: Hardware details such as processors and secure hardware

- - **Connectivity**: Connectivity options, protocols, and interfaces such as radio(s) and GPIO

- - **Accelerators**: Specify hardware acceleration such as GPU and VPU

- - **Sensors**: Specify available sensors such as GPS and vibration

- - **Additional Specs**: Additional information about the device such as physical dimensions and storage/battery information

-1. Select `Save Product Details` at the bottom of the Product details page.

-## Component use requirements and recommendations

-You may have questions regarding how many components to include, or what component type to use. Below are examples of a few sample scenarios of devices that you may be certifying, and how you can use the components feature.

-| Product Type | No. Components | Component 1 / Attachment Type | Components 2+ / Attachment Type |

-|-||-|--|

-| Finished Product | 1 | Customer Ready Product, Discrete | N/A |

-| Finished Product with **detachable peripheral(s)** | 2 or more | Customer Ready Product, Discrete | Peripheral / Discrete or Integrated |

-| Finished Product with **integrated component(s)** | 2 or more | Customer Ready Product, Discrete | Select appropriate type / Discrete or integrated |

-| Solution-Ready Dev Kit | 1 or more | Customer Ready Product or Development Board, Discrete or Integrated| Select appropriate type / Discrete or integrated |

-## Example component usage

-Below are examples of how an OEM called Contoso would use the components feature to certify their product, called Falcon.

-1. Falcon is a complete stand-alone device that does not integrate into a larger product.

- 1. No. of components: 1

- 1. Component device type: Customer Ready Product

- 1. Attachment type: Discrete

- 

-1. Falcon is a device that includes an integrated peripheral camera module manufactured by INC Electronics that connects via USB to Falcon.

- 1. No. of components: 2

- 1. Component device type: Customer Ready Product, Peripheral

- 1. Attachment type: Discrete, Integrated

-

- > [!Note]

- > The peripheral component is considered integrated because it is not removable.

- 

-1. Falcon is a device that includes an integrated System on Module from INC Electronics that uses a built-in processor Apollo52 from company Espressif and has an ARM64 architecture.

- 1. No. of components: 2

- 1. Component device type: Customer Ready Product, System on Module

- 1. Attachment type: Discrete, Integrated

- > [!Note]

- > The peripheral component is considered integrated because it is not removable. The SoM component would also include processor information.

- 

-## Additional tips

-We've provided below more clarifications regarding our component usage policy. If you have any questions about appropriate component usage, contact our team at [iotcert@microsoft.com](mailto:iotcert@microsoft.com), and we'll be more than happy to help!

-1. A project must contain **only** one Customer Ready Product component. If you are certifying a project with two independent devices, those devices should be certified separately.

-1. It is primarily up to you to use (or not use) components to promote your device's capabilities to potential customers.

-1. During our review of your device, the Azure Certification team will only require at least one Customer Ready Product component to be listed. However, we may request edits to the component information if the details are not clear or appear to be lacking (for example, component manufacturer is not supplied for a Customer Ready Product type).

-## Next steps

-Now that you're ready to use our components feature, you're now ready to complete your device details or edit your project for further clarity.

-description: An overview of the Azure Certified Device program for our partners and customers. Use these resources to start the device certification process. Find out how to certify your device, from IoT device requirements to publishing your device.

-# What is the Azure Certified Device program?

-> [!Note]

-> The Azure Certified Device program has met its goals and will conclude on February 23, 2024. This means that the Azure Certified Device catalog, along with certifications for Azure Certified Device, Edge Managed, and IoT Plug and Play will no longer be available after this date. However, the Edge Secured-core program will remain active and will be relocated to a new home at [aka.ms/EdgeSecuredCoreHome](https://aka.ms/EdgeSecuredCoreHome).

-Thank you for your interest in the Azure Certified Device program! Azure Certified Device is a free program that enables you to differentiate, certify, and promote your IoT devices built to run on Azure. From intelligent cameras to connected sensors to edge infrastructure, this enhanced IoT device certification program helps device builders increase their product visibility and saves customers time in building solutions.

-## Our certification promise

-The Azure Certified Device program ensures customer solutions work great on Azure. It is a program that utilizes tools, services, and a catalog to share industry knowledge with our community of builders within the IoT ecosystem to help builders and customers alike.

-Across the device certification process, the three tenets of this program are:

-The Azure Certified Device program serves two different audiences.

-1. **Device builders**: Do you build IoT devices? Easily differentiate your IoT device capabilities and gain access to a worldwide audience looking to reliably purchase devices built to run on Azure. Use the Azure Certified Device Catalog to increase product visibility and connect with customers by certifying your device and show it meets specific IoT device requirements.

-1. **Solution builders**: Wondering what are IoT qualified devices? Confidently find and purchase IoT devices built to run on Azure, knowing they meet specific IoT requirements. Easily search and select the right certified device for your IoT solution on the [Azure Certified Device catalog](https://devicecatalog.azure.com/).

-## Our certification programs and IoT device requirements.

-There are four different certifications available now! Each certification is focused on delivering a different customer value. Depending on the type of device and your target audience, you can choose which certification(s) is most applicable for you to apply for. Select the titles of each program to learn more about the program and IoT requirements.

-| Certification program | Overview |

-|-|

-| [Azure Certified Device](program-requirements-azure-certified-device.md) | Azure Certified Device certification validates that a device can connect with Azure IoT Hub and securely provision through the Device Provisioning Service (DPS). This certification reflects a device's functionality and interoperability, which are a **required baseline** for all other certifications. |

-| [IoT Plug and Play](program-requirements-pnp.md) | IoT Plug and Play certification, an incremental certification beyond the baseline Azure Certified Device certification, validates Digital Twin Definition Language version 2 (DTDL) and interaction based on your device model. It enables a seamless device-to-cloud integration experience and enables hardware partners to build devices that can seamlessly integrate without the need to write custom code. |

-| [Edge Managed](program-requirements-edge-managed.md) | Edge Managed certification, an incremental certification beyond the baseline Azure Certified Device certification, focuses on device management standards for Azure connected devices. |

-| [Edge Secured Core](program-requirements-edge-secured-core.md) | Edge Secured-core certification, an incremental certification beyond the baseline Azure Certified Device certification, is for IoT devices running a full operating system such as Linux or Windows 10 IoT. It validates devices meet additional security requirements around device identity, secure boot, operating system hardening, device updates, data protection, and vulnerability disclosures. |

-## How to certify your device

-Certifying a device involves several major steps on the [Azure Certified Device portal](https://certify.azure.com):

-1. Select the right certification for your device based on the IoT device requirements.

-1. Create your project in the [Azure Certified Device portal](https://certify.azure.com).

-1. Add device details including hardware capability information to begin the device certification process.

-1. Validate device functionality

-1. Submit and complete the review process

-> [!Note]

-> The review process can take up to a week to complete, though sometimes may take longer.

-Once you have certified your device, you then can optionally complete two of the following activities:

-1. Publishing to the Azure Certified Device Catalog (optional)

-1. Updating your project after it has been approved/published (optional)

-Ready to get started with your certification journey? View our resources below to start the device certification process!

-description: Azure Certified Device Certification Requirements

-# Azure Certified Device Certification Requirements

-> [!Note]

-> The Azure Certified Device program has met its goals and will conclude on February 23, 2024. This means that the Azure Certified Device catalog, along with certifications for Azure Certified Device, Edge Managed, and IoT Plug and Play will no longer be available after this date. However, the Edge Secured-core program will remain active and will be relocated to a new home at [aka.ms/EdgeSecuredCoreHome](https://aka.ms/EdgeSecuredCoreHome).

-This document outlines the device specific capabilities that will be represented in the Azure Certified Device catalog. A capability is singular device attribute that may be software implementation or combination of software and hardware implementations.

-## Program Purpose

-Microsoft is simplifying IoT and Azure Certified Device certification is baseline certification program to ensure any device types are provisioned to Azure IoT Hub securely.

-Promise of Azure Certified Device certification are:

-1. Device support telemetry that works with IoT Hub

-2. Device support IoT Hub Device Provisioning Service (DPS) to securely provisioned to Azure IoT Hub

-3. Device supports easy input of target DPS ID scope transfer without requiring user to recompile embedded code.

-4. Optionally validates other elements such as cloud to device messages, direct methods and device twin

-## Requirements

-**[Required] Device to cloud: The purpose of test is to make sure devices that send telemetry works with IoT Hub**

-| **Name** | AzureCertified.D2C |

-| -- | |

-| **Target Availability** | Available now |

-| **Applies To** | Leaf device/Edge device |

-| **OS** | Agnostic |

-| **Validation Type** | Automated |

-| **Validation** | Device must send any telemetry schemas to IoT Hub. Microsoft provides the [portal workflow](https://certify.azure.com/) to execute the tests. Device to cloud (required): **1.** Validates that the device can send message to AICS managed IoT Hub **2.** User must specify the number and frequency of messages. **3.** AICS validates the telemetry is received by the Hub instance |

-| **Resources** | [Certification steps](./overview.md) (has all the additional resources) |

-**[Required] DPS: The purpose of test is to check the device implements and supports IoT Hub Device Provisioning Service with one of the three attestation methods**

-| **Name** | AzureCertified.DPS |

-| -- | |

-| **Target Availability** | New |

-| **Applies To** | Any device |

-| **OS** | Agnostic |

-| **Validation Type** | Automated |

-| **Validation** | Device supports easy input of target DPS ID scope ownership. Microsoft provides the [portal workflow](https://certify.azure.com) to execute the tests to validate that the device supports DPS **1.** User must select one of the attestation methods (X.509, TPM and SAS key) **2.** Depending on the attestation method, user needs to take corresponding action such as **a)** Upload X.509 cert to AICS managed DPS scope **b)** Implement SAS key or endorsement key into the device |

-| **Resources** | [Device provisioning service overview](../iot-dps/about-iot-dps.md) |

-**[If implemented] Cloud to device: The purpose of test is to make sure messages can be sent from cloud to devices**

-| **Name** | AzureCertified.C2D |

-| -- | |

-| **Target Availability** | Available now |

-| **Applies To** | Leaf device/Edge device |

-| **OS** | Agnostic |

-| **Validation Type** | Automated |

-| **Validation** | Device must be able to Cloud to Device messages from IoT Hub. Microsoft provides the [portal workflow](https://certify.azure.com) to execute these tests.Cloud to device (if implemented): **1.** Validates that the device can receive message from IoT Hub **2.** AICS sends random message and validates via message ACK from the device |

-| **Resources** | **a)** [Certification steps](./overview.md) (has all the additional resources) **b)** [Send cloud to device messages from an IoT Hub](../iot-hub/iot-hub-devguide-messages-c2d.md) |

-**[If implemented] Direct methods: The purpose of test is to make sure devices works with IoT Hub and supports direct methods**

-| **Name** | AzureCertified.DirectMethods |

-| -- | |

-| **Target Availability** | Available now |

-| **Applies To** | Leaf device/Edge device |

-| **OS** | Agnostic |

-| **Validation Type** | Automated |

-| **Validation** | Device must be able to receive and reply commands requests from IoT Hub. Microsoft provides the [portal workflow](https://certify.azure.com) to execute the tests. Direct methods (if implemented) **1.** User has to specify the method payload of direct method. **2.** AICS validates the specified payload request is sent from Hub and ACK message received by the device |

-| **Resources** | **a)** [Certification steps](./overview.md) (has all the additional resources) **b)** [Understand direct methods from IoT Hub](../iot-hub/iot-hub-devguide-direct-methods.md) |

-**[If implemented] Device twin property: The purpose of test is to make sure devices that send telemetry works with IoT Hub and supports some of the IoT Hub capabilities such as direct methods, and device twin property**

-| **Name** | AzureCertified.DeviceTwin |

-| -- | |

-| **Target Availability** | Available now |

-| **Applies To** | Leaf device/Edge device |

-| **OS** | Agnostic |

-| **Validation Type** | Automated |

-| **Validation** | Device must send any telemetry schemas to IoT Hub. Microsoft provides the [portal workflow](https://certify.azure.com) to execute the tests. Device twin property (if implemented) **1.** AICS validates the read/write-able property in device twin JSON **2.** User has to specify the JSON payload to be changed **3.** AICS validates the specified desired properties sent from IoT Hub and ACK message received by the device |

-| **Resources** | **a)** [Certification steps](./overview.md) (has all the additional resources) **b)** [Use device twins with IoT Hub](../iot-hub/iot-hub-devguide-device-twins.md) |

-**[Required] Limit Recompile: The purpose of this policy ensures devices by default should not need users to re-compile code to deploy the device.**

-| **Name** | AzureCertified.Policy.LimitRecompile |

-| -- | |

-| **Target Availability** | Policy |

-| **Applies To** | Any device |

-| **OS** | Agnostic |

-| **Validation Type** | Policy |

-| **Validation** | To simplify device configuration for users, we require all devices can be configured to connect to Azure without the need to recompile and deploy device source code. This includes DPS information, such as Scope ID, which should be set as configuration settings and not compiled. However, if your device contains certain secure hardware or if there are extenuating circumstances in which the user will expect to compile and deploy code, contact the certification team to request an exception review. |

-| **Resources** | **a)** [Device provisioning service overview](../iot-dps/about-iot-dps.md) **b)** Sample config file for DPS ID Scope transfer |

-description: Edge Managed Certification Requirements

-# Edge Managed Certification Requirements

-> [!Note]

-> The Azure Certified Device program has met its goals and will conclude on February 23, 2024. This means that the Azure Certified Device catalog, along with certifications for Azure Certified Device, Edge Managed, and IoT Plug and Play will no longer be available after this date. However, the Edge Secured-core program will remain active and will be relocated to a new home at [aka.ms/EdgeSecuredCoreHome](https://aka.ms/EdgeSecuredCoreHome).

-This document outlines the device specific capabilities that will be represented in the Azure Certified Device catalog. A capability is singular device attribute that may describe the device.

-## Program Purpose

-Edge Managed certification, an incremental certification beyond the baseline Azure Certified Device certification. Edge Managed focuses on device management standards for Azure connected devices and validates the IoT Edge runtime compatibility for module deployment and management. (Previously, this program was identified as the IoT Edge certification program.)

-Edge Managed certification validates IoT Edge runtime compatibility for module deployment and management. This program provides confidence in the management of Azure connected IoT devices.

-## Requirements

-The Edge Managed certification requires that all requirements from the [Azure Certified Device baseline program](.\program-requirements-azure-certified-device.md).

-**DPS: The purpose of test is to check the device implements and supports IoT Hub Device Provisioning Service with one of the three attestation methods**

-| **Name** | AzureReady.DPS |

-| -- | |

-| **Target Availability** | Available now |

-| **Applies To** | Any device |

-| **OS** | Agnostic |

-| **Validation Type** | Automated |

-| **Validation** | AICS validates the device code support DPS. **1.** User has to select one of the attestation methods (X.509, TPM and SAS key). **2.** Depending on the attestation method, user needs to take corresponding action such as **a)** Upload X.509 cert to AICS managed DPS scope **b)** Implement SAS key or endorsement key into the device. **3.** Then, user will hit ΓÇÿConnectΓÇÖ button to connect to AICS managed IoT Hub via DPS |

-| **Resources** | |

-| **Azure Recommended:** | N/A |

-## IoT Edge

-**Edge runtime exists: The purpose of test is to make sure the device contains IoT Edge runtime ($edgehub and $edgeagent) are functioning correctly.**

-| **Name** | EdgeManaged.EdgeRT |

-| -- | |

-| **Target Availability** | Available now |

-| **Applies To** | IoT Edge device |

-| **OS** | [Tier1 and Tier2 OS](../iot-edge/support.md) |

-| **Validation Type** | Automated |

-| **Validation** | AICS validates the deploy-ability of the installed IoT Edge RT. **1.** User needs to specify specific OS (OS not on the list of Tier1/2 are not accepted) **2.** AICS generates its config.yaml and deploys canonical [simulated temp sensor edge module](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/azure-iot.simulated-temperature-sensor?tab=Overview) **3.** AICS validates that docker compatible container subsystem (Moby) is installed on the device **4.** Test result is determined based on successful deployment of the simulated temp sensor edge module and functionality of docker compatible container subsystem |

-| **Resources** | **a)** [AICS blog](https://azure.microsoft.com/blog/expanding-azure-iot-certification-service-to-support-azure-iot-edge-device-certification/), **b)** [Certification steps](./overview.md) (has all the additional resources), **c)** [Requirements](./program-requirements-azure-certified-device.md) |

-| **Azure Recommended:** | N/A |

-### Capability Template:

-**IoT Edge easy setup: The purpose of test is to make sure IoT Edge device is easy to set up and validates IoT Edge runtime is preinstalled during physical device validation**

-| **Name** | EdgeManaged.PhysicalDevice |

-| -- | |

-| **Target Availability** | Available now (currently on hold due to COVID-19) |

-| **Applies To** | IoT Edge device |

-| **OS** | [Tier1 and Tier2 OS](../iot-edge/support.md) |

-| **Validation Type** | Manual / Lab Verified |

-| **Validation** | OEM must ship the physical device to IoT administration (HCL). HCL performs manual validation on the physical device to check: **1.** EdgeRT is using Moby subsystem (allowed redistribution version). Not docker **2.** Pick the latest edge module to validate ability to deploy edge. |

-| **Resources** | **a)** [AICS blog](https://azure.microsoft.com/blog/expanding-azure-iot-certification-service-to-support-azure-iot-edge-device-certification/), **b)** [Certification steps](./overview.md) , **c)** [Requirements](./program-requirements-azure-certified-device.md) |

-| **Azure Recommended:** | N/A |

-# Azure Certified Device - Edge Secured-core #

-## Edge Secured-Core certification requirements ##

-### Program purpose ###

-Edge Secured-core is a security certification for devices running a full operating system. Edge Secured-core currently supports Windows IoT and Azure Sphere OS. Linux support is coming in the future. This program enables device partners to differentiate their devices by meeting an additional set of security criteria. Devices meeting this criteria enable these promises:

-1. Hardware-based device identity

-2. Capable of enforcing system integrity

-3. Stays up to date and is remotely manageable

-4. Provides data at-rest protection

-5. Provides data in-transit protection

-6. Built in security agent and hardening

-Edge Secured-core for Windows IoT requires Windows 10 IoT Enterprise version 1903 or greater

-> [!Note]

-> The Windows secured-core tests require you to download and run the following package (https://aka.ms/Scforwiniot) from an Administrator Command Prompt on the IoT device being validated.

-> * Kernel DMA Protection (also known as Memory Access Protection)

-|Description|The purpose of the requirement is to validate the device identity is rooted in hardware and can be the primary authentication method with Azure IoT Hub Device Provisioning Service (DPS).|

-|Requirements dependency|TPM v2.0 device|

-|Validation Type|Manual/Tools|

-|Validation|Devices are enrolled to DPS using the TPM authentication mechanism during testing.|

-|Resources|Azure IoT Hub Device Provisioning Service: <ul><li>[Quickstart - Provision a simulated TPM device to Microsoft Azure IoT Hub](../iot-dps/quick-create-simulated-device-tpm.md) </li><li>[TPM Attestation Concepts](../iot-dps/concepts-tpm-attestation.md)</li></ul>|

-|Description|The purpose of the requirement is to validate that DMA isn't enabled on externally accessible ports.|

-|Requirements dependency|Only if DMA capable ports exist|

-|Validation Type|Manual/Tools|

-|Validation|If DMA capable external ports exist on the device, toolset to validate that the IOMMU, or SMMU is enabled and configured for those ports.|

-|Description|The purpose of the requirement is to ensure that device has adequate mitigations from Firmware security threats.|

-|Requirements dependency|DRTM + UEFI|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through [Edge Secured-core Agent](https://aka.ms/Scforwiniot) toolset to confirm it's protected from firmware security threats through one of the following approaches: <ul><li>DRTM + UEFI Management Mode mitigations</li><li>DRTM + UEFI Management Mode hardening</li></ul> |

-|Resources| <ul><li>https://trustedcomputinggroup.org/</li><li>[Intel's DRTM based computing whitepaper](https://www.intel.com/content/dam/www/central-libraries/us/en/documents/drtm-based-computing-whitepaper.pdf)</li><li>[AMD Security whitepaper](https://www.amd.com/system/files/documents/amd-security-white-paper.pdf)</li></ul> |

-|Description|The purpose of the requirement is to validate the boot integrity of the device.|

-|Requirements dependency|UEFI|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through [Edge Secured-core Agent](https://aka.ms/Scforwiniot) toolset to ensure that firmware and kernel signatures are validated every time the device boots. <ul><li>UEFI: Secure boot is enabled</li></ul>|

-|Description|The purpose of the requirement is to ensure the device can remotely attest to the Microsoft Azure Attestation service.|

-|Requirements dependency|Azure Attestation Service|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that platform boot logs and measurements of boot activity can be collected and remotely attested to the Microsoft Azure Attestation service.|

-|Resources| [Microsoft Azure Attestation](../attestation/index.yml) |

-## Windows IoT configuration requirements

-|Description|The purpose of the requirement to validate that sensitive data can be encrypted on nonvolatile storage.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through [Edge Secured-core Agent](https://aka.ms/Scforwiniot) toolset to ensure Secure-boot and BitLocker is enabled and bound to PCR7.|

-|Description|The purpose of the requirement is to validate support for required TLS versions and cipher suites.|

-|Requirements dependency|Windows 10 IoT Enterprise Version 1903 or greater. Note: other requirements might require greater versions for other services. |

-|Validation Type|Manual/Tools|

-Validation|Device to be validated through toolset to ensure the device supports a minimum TLS version of 1.2 and supports the following required TLS cipher suites.<ul><li>TLS_RSA_WITH_AES_128_GCM_SHA256</li><li>TLS_RSA_WITH_AES_128_CBC_SHA256</li><li>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</li><li>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</li><li>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</li><li>TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256</li><li>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256</li></ul>|

-|Resources| [TLS support in IoT Hub](../iot-hub/iot-hub-tls-support.md) <br /> [TLS Cipher suites in Windows 10](/windows/win32/secauthn/tls-cipher-suites-in-windows-10-v1903) |

-|Description|The purpose of this requirement is to validate that code integrity is available on this device.|

-|Requirements dependency|HVCI is enabled on the device.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through [Edge Secured-core Agent](https://aka.ms/Scforwiniot) toolset to ensure that HVCI is enabled on the device.|

-|Resources| [Hypervisor-protected Code Integrity enablement](/windows-hardware/design/device-experiences/oem-hvci-enablement) |

-|Description|The purpose of the requirement is to validate that services listening for input from the network aren't running with elevated privileges.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through [Edge Secured-core Agent](https://aka.ms/Scforwiniot) toolset to ensure that third party services accepting network connections aren't running with elevated LocalSystem and LocalService privileges. <ol><li>Exceptions might apply</li></ol>|

-|Description|The purpose of the requirement is to make sure devices can report security information and events by sending data to Azure Defender for IoT. <br>Note: Download and deploy security agent from GitHub|

-|Target Availability|2022|

-|Validation Type|Manual/Tools|

-|Validation |Device must generate security logs and alerts. Device logs and alerts messages to Azure Security Center.<ol><li>Device must have the Azure Defender microagent running</li><li>Configuration_Certification_Check must report TRUE in the module twin</li><li>Validate alert messages from Azure Defender for IoT.</li></ol>|

-|Resources|[Azure Docs IoT Defender for IoT](../defender-for-iot/how-to-configure-agent-based-solution.md)|

-|Description|The purpose of the requirement is to validate that the system conforms to a baseline security configuration.|

-|Target Availability|2022|

-|Requirements dependency|Azure Defender for IoT|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that Defender IOT system configurations benchmarks have been run.|

-|Resources| https://techcommunity.microsoft.com/t5/microsoft-security-baselines/bg-p/Microsoft-Security-Baselines <br> https://www.cisecurity.org/cis-benchmarks/ |

-## Windows IoT Policy Requirements

-Some requirements of this program are based on a business agreement between your company and Microsoft. The following requirements aren't validated through our test harness, but are required by your company in certifying the device.

-</br>

-|Description|The purpose of the requirement is to validate that debug functionality on the device is disabled.|

-|Requirements dependency||

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that debug functionality requires authorization to enable.|

-|Description|The purpose of this requirement is to validate the device against two use cases: a) Ability to perform a reset (remove user data, remove user configs), b) Restore device to last known good in the case of an update causing issues.|

-|Requirements dependency||

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through a combination of toolset and submitted documentation that the device supports this functionality. The device manufacturer can determine whether to implement these capabilities to support remote reset or only local reset.|

-|Description|The purpose of this policy is to ensure that the device remains secure.|

-|Validation Type|Manual|

-|Validation|Commitment from submission that devices certified can be kept up to date for 60 months from date of submission. Specifications available to the purchaser and devices itself in some manner should indicate the duration for which their software will be updated.|

-|Description|The purpose of this policy is to ensure that there's a mechanism for collecting and distributing reports of vulnerabilities in the product.|

-|Validation Type|Manual|

-|Validation|Documentation on the process for submitting and receiving vulnerability reports for the certified devices will be reviewed.|

-|Description|The purpose of this policy is to ensure that vulnerabilities that are high/critical (using CVSS 3.0) are addressed within 180 days of the fix being available.|

-|Validation Type|Manual|

-|Validation|Documentation on the process for submitting and receiving vulnerability reports for the certified devices will be reviewed.|

-> Linux is not yet supported. The below represent expected requirements. Please contact iotcert@microsoft.com if you are interested in certifying a Linux device, including device HW and OS specs, and whether or not it meets each of the draft requirements below.

-|Description|The purpose of the requirement is to validate the device identify is rooted in hardware.|

-|Requirements dependency|TPM v2.0 </br>^{or *other supported method}|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that the device has a HWRoT present and that it can be provisioned through DPS using TPM or SE.|

-|Resources|[Setup auto provisioning with DPS](../iot-dps/quick-setup-auto-provision.md)|

-|Description|The purpose of the requirement is to validate ensure that memory integrity helps protect the device from vulnerable peripherals.|

-|Validation Type|Manual/Tools|

-|Validation|memory regions for peripherals must be gated with hardware/firmware such as memory region domain controllers or SMMU (System memory management Unit).|

-|Description|The purpose of the requirement is to ensure that device has adequate mitigations from Firmware security threats.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to confirm it's protected from firmware security threats through one of the following approaches: <ul><li>Approved FW that does SRTM + runtime firmware hardening</li><li>Firmware scanning and evaluation by approved Microsoft third party</li></ul> |

-|Resources| https://trustedcomputinggroup.org/ |

-|Description|The purpose of the requirement is to validate the boot integrity of the device.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that firmware and kernel signatures are validated every time the device boots. <ul><li>UEFI: Secure boot is enabled</li><li>Uboot: Verified boot is enabled</li></ul>|

-|Description|The purpose of the requirement is to ensure the device can remotely attest to the Microsoft Azure Attestation service.|

-|Dependency|TPM 2.0 </br>^{or *supported OP-TEE based application chained to a HWRoT (Secure Element or Secure Enclave)}|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that platform boot logs and applicable runtime measurements can be collected and remotely attested to the Microsoft Azure Attestation service.|

-|Resources| [Microsoft Azure Attestation](../attestation/index.yml) </br> Certification portal test includes an attestation client that when combined with the TPM 2.0 can validate the Microsoft Azure Attestation service.|

-|Status|Required|

-|Description|The purpose of the requirement to validate the existence of a secure enclave and that the enclave can be used for security functions.|

-|Validation Type|Manual/Tools|

-|Validation||

-|Description|The purpose of the requirement to validate that sensitive data can be encrypted on nonvolatile storage.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure storage encryption is enabled and default algorithm is XTS-AES, with key length 128 bits or higher.|

-|Description|The purpose of the requirement is to validate support for required TLS versions and cipher suites.|

-|Validation Type|Manual/Tools|

-Validation|Device to be validated through toolset to ensure the device supports a minimum TLS version of 1.2 and supports the following required TLS cipher suites.<ul><li>TLS_RSA_WITH_AES_128_GCM_SHA256</li><li>TLS_RSA_WITH_AES_128_CBC_SHA256</li><li>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</li><li>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</li><li>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</li><li>TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256</li><li>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256</li></ul>|

-|Resources| [TLS support in IoT Hub](../iot-hub/iot-hub-tls-support.md) <br /> |

-|Description|The purpose of this requirement is to validate that authorized code runs with least privilege.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that code integrity is enabled by validating dm-verity and IMA|

-|Status|^*Required|

-|Description|The purpose of the requirement is to validate that applications accepting input from the network aren't running with elevated privileges.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that services accepting network connections aren't running with SYSTEM or root privileges.|

-|Description|The purpose of the requirement is to make sure devices can report security information and events by sending data to Microsoft Defender for IoT.|

-|Validation Type|Manual/Tools|

-|Validation |<ol><li>Device must generate security logs and alerts.</li><li>Device logs and alerts messages to Azure Security Center.</li><li>Device must have the Azure Defender for IoT microagent running</li><li>Configuration_Certification_Check must report TRUE in the module twin</li><li>Validate alert messages from Azure Defender for IoT.</li></ol>|

-|Resources|[Azure Docs IoT Defender for IoT](../defender-for-iot/how-to-configure-agent-based-solution.md)|

-|Description|The purpose of the requirement is to validate that device supports auditing and setting of system configuration (and certain management actions such as reboot) through Azure.|

-|Validation Type|Manual/Tools|

-|Validation|<ol><li>Device must report, via IoT Hub, its firewall state, firewall fingerprint, ip addresses, network adapter state, host name, hosts file, TPM (absence, or presence with version) and package manager sources (see What can I manage) </li><li>Device must accept the creation, via IoT Hub, of a default firewall policy (accept vs drop), and at least one firewall rule, with positive remote acknowledgment (see configurationStatus)</li><li>Device must accept the replacement of /etc/hosts file contents via IoT Hub, with positive remote acknowledgment (see https://learn.microsoft.com/en-us/azure/osconfig/howto-hosts?tabs=portal#the-object-model )</li><li>Device must accept and implement, via IoT Hub, remote reboot</li></ol> Note: Use of other system management toolchains (for example, Ansible, etc.) by operators are not prohibited, but the device must include the azure-osconfig agent such that it's ready to be managed from Azure.|

-|Description|The purpose of the requirement is to validate the device can receive and update its firmware and software.|

-|Validation Type|Manual/Tools|

-|Validation|Partner confirmation that they were able to send an update to the device through Azure Device update and other approved services.|

-|Resources|[Device Update for IoT Hub](../iot-hub-device-update/index.yml)|

-|Name|SecuredCore.Protection.Baselines|

-|Description|The purpose of the requirement is to validate the extent to which the device implements the Azure Security Baseline|

-|Dependency|azure-osconfig|

-|Validation Type|Manual/Tools|

-|Validation|OSConfig is present on the device and reporting to what extent it implements the Azure Security Baseline.|

-|Resources|<ul><li>https://techcommunity.microsoft.com/t5/microsoft-security-baselines/bg-p/Microsoft-Security-Baselines</li><li>https://www.cisecurity.org/cis-benchmarks/</li><li>https://learn.microsoft.com/en-us/azure/governance/policy/samples/guest-configuration-baseline-linux</li></ul>|

-|Name|SecuredCore.Protection.SignedUpdates|

-|Description|The purpose of the requirement is to validate that updates must be signed.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that updates to the operating system, drivers, application software, libraries, packages and firmware won't be applied unless properly signed and validated.

-|Description|The purpose of the requirement is to validate that debug functionality on the device is disabled.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that debug functionality requires authorization to enable.|

-|Description|The purpose of this requirement is to validate the device against two use cases: a) Ability to perform a reset (remove user data, remove user configs), b) Restore device to last known good if an update causing issues.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through a combination of toolset and submitted documentation that the device supports this functionality. The device manufacturer can determine whether to implement these capabilities to support remote reset or only local reset.|

-|Description|The purpose of this policy is to ensure that the device remains secure.|

-|Validation Type|Manual|

-|Validation|Commitment from submission that devices certified will be required to keep devices up to date for 60 months from date of submission. Specifications available to the purchaser and devices itself in some manner should indicate the duration for which their software will be updated.|

-|Description|The purpose of this policy is to ensure that there's a mechanism for collecting and distributing reports of vulnerabilities in the product.|

-|Validation Type|Manual|

-|Validation|Documentation on the process for submitting and receiving vulnerability reports for the certified devices will be reviewed.|

-|Description|The purpose of this policy is to ensure that vulnerabilities that are high/critical (using CVSS 3.0) are addressed within 180 days of the fix being available.|

-|Validation Type|Manual|

-|Validation|Documentation on the process for submitting and receiving vulnerability reports for the certified devices will be reviewed.|

-## Azure Sphere platform Support

-The Mediatek MT3620AN must be included in your design. Additional guidance for building secured Azure Sphere applications can be within the [Azure Sphere application notes](/azure-sphere/app-notes/app-notes-overview).

-|Description|The purpose of the requirement is to validate the device identity is rooted in hardware.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the requirement is to ensure that memory integrity helps protect the device from vulnerable peripherals.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the requirement is to ensure that device has adequate mitigations from Firmware security threats.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the requirement is to validate the boot integrity of the device.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the requirement is to ensure the device can remotely attest to a Microsoft Azure Attestation service.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of this requirement is to validate hardware security that is accessible from a secure operating system.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of this requirement is to validate that sensitive data can be encrypted on nonvolatile storage.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Resources|[Data at rest protection on Azure Sphere](/azure-sphere/app-notes/app-notes-overview)|

-|Description|The purpose of the requirement is to validate support for required TLS versions and cipher suites.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Resources| [TLS support in IoT Hub](../iot-hub/iot-hub-tls-support.md) <br /> |

-|Description|The purpose of this requirement is to validate that authorized code runs with least privilege.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the requirement is to validate that applications accepting input from the network aren't running with elevated privileges.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of this requirement is to validate that applications can't connect to endpoints that haven't been authorized.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of this requirement is to make sure devices can report security information and events by sending data to a Microsoft telemetry service.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of this requirement is to validate the device supports remote administration via service-based configuration control.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the requirement is to validate the device can receive and update its firmware and software.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the requirement is to validate that the system conforms to a baseline security configuration|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Name|SecuredCore.Protection.SignedUpdates|

-|Description|The purpose of the requirement is to validate that updates must be signed.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the policy requires that debug functionality on the device is disabled.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The policy requires that the device can execute two use cases: a) Ability to perform a reset (remove user data, remove user configurations), b) Restore device to last known good in the case of an update causing issues.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of this policy is to ensure that the device remains secure.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of this policy is to ensure that there's a mechanism for collecting and distributing reports of vulnerabilities in the product.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Azure Sphere vulnerabilities are collected by Microsoft through MSRC and are published to customers through the Tech Community Blog, Azure Sphere ΓÇ£WhatΓÇÖs NewΓÇ¥ page, and through MitreΓÇÖs CVE database.|

-|Description|The purpose of this policy is to ensure that vulnerabilities that are high/critical (using CVSS 3.0) are addressed within 180 days of the fix being available.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-description: A list of common terms used in the Azure Certified Device program

-# Azure Certified Device program glossary

-This guide provides definitions of terms commonly used in the Azure Certified Device program and portal. Refer to this glossary for clarification to the certification process. For your convenience, this glossary is categorized based on major certification concepts that you may have questions about.

-## Device class

-When creating your certification project, you will be asked to specify a device class. Device class refers to the form factor or classification that best represents your device.

- A device that processes data sent over an IoT network.

- A device that detects and responds to changes to an environment and connects to gateways to process the changes.

- If you select Other, add a description of your device class in your own words. Over time, we may continue to add new values to this list, particularly as we continue to monitor feedback from our partners.

-## Device type

-You will also be asked to select one of two device types during the certification process.

- A device that is solution-ready and ready for production deployment. Typically in a finished form factor with firmware and an operating system. These may be general-purpose devices that require additional customization or specialized devices that require no modifications for usage.

- A development kit containing hardware and software ideal for easy prototyping, typically not in a finished form factor. Usually includes sample code and tutorials to enable quick prototyping.

-## Component type

-In the Device details section, you'll describe your device by listing components by component type. You can view more guidance on components [here](./how-to-using-the-components-feature.md).

- A component representation of the overall or primary device. This is different from a **Finished Product**, which is a classification of the device as being ready for customer use without further development. A Finished Product will contain a Customer Ready Product component.

- Either an integrated or detachable board with microprocessor for easy customization.

- Either an integrated or detachable addition to the product (such as an accessory). These are typically devices that connect to the main device, but does not contribute to device primary functions. Instead, it provides additional functions. Memory, RAM, storage, hard disks, and CPUs are not considered peripheral devices (they instead should be listed under Additional Specs of the Customer Ready Product component).

- A board-level circuit that integrates a system function in a single module.

-## Component attachment method

-Component attachment method is another component detail that informs the customer about how the component is integrated into the overall product.

-

- Refers to when a device component is a part of the main chassis of the product. This most commonly refers to a peripheral component type that cannot be removed from the device.

- Example: An integrated temperature sensor inside a gateway chassis.

- Refers to when a component is **not** a part of main chassis of the product.

- Example: An external temperature sensor that must be attached to the device.

-## Next steps

-This glossary will guide you through the process of certifying your project on the portal. You're now ready to begin your project!

-description: Step-by-step guide to selecting the right certification programs for your device

-# Tutorial: Select your certification program

-Congratulations on choosing the Azure Certified Device program! We're excited to have you join our ecosystem of certified devices. To begin, you must first determine which certification programs best suit your device capabilities.

-In this tutorial, you learn to:

-> [!div class="checklist"]

-> * Select the best certification program(s) for your device

-## Selecting a certification program for your device

-All devices are required to meet the baseline requirements outlined by the **Azure Certified Device** certification. To better promote your device and help set it apart, we offer optional certification programs (ΓÇ£IoT Plug and PlayΓÇ¥, ΓÇ£Edge ManagedΓÇ¥ and ΓÇ£Edge Secured-core *preview") that validate additional capabilities.

-1. Review each of the certification programs' in the table below to help identify which program is best suited to promote your device.

- |Program Requirements|Processor|Architecture|OS|

- |||

- [Azure Certified Device](./program-requirements-azure-certified-device.md)|Any|Any|Any|

- [IoT Plug and Play](./program-requirements-edge-secured-core.md)|Any|Any|Any|

- [Edge Managed](./program-requirements-edge-managed.md)|MPU/CPU|ARM/x86/AMD64|[Tier 1 OS](../iot-edge/support.md?view=iotedge-2018-06&preserve-view=true)|

- [*Edge Secured-core](./program-requirements-edge-secured-core.md)|MPU/CPU|ARM/AMD64|[Tier 1 OS](../iot-edge/support.md?view=iotedge-2018-06&preserve-view=true)|

-

-1. Review the specific requirements for the selected program and make sure your device is prepared to connect to Azure to validate the requirements.

-## Next steps

-You're now ready to begin certifying your device! Advance to the next article to begin your project.

-> [!div class="nextstepaction"]

->[Tutorial: Creating your project](tutorial-01-creating-your-project.md)

-description: Guide to create a project on the Azure Certified Device portal

-# Tutorial: Create your project

-Congratulations on choosing to certify your device through the Azure Certified Device program! You've now selected the appropriate certification program for your device, and are ready to get started on the portal.

-In this tutorial, you will learn how to:

-> [!div class="checklist"]

-> * Sign into the [Azure Certified Device portal](https://certify.azure.com/)

-> * Create a new certification project for your device

-> * Specify basic device details of your project

-## Prerequisites

-> [!NOTE]

-> If you're having problems setting up or validating your MPN account, see the [Partner Center Support](/partner-center) documentation.

-## Signing into the Azure Certified Device portal

-To get started, you must sign in to the portal, where you'll be providing your device information, completing certification testing, and managing your device publications to the Azure Certified Device catalog.

-1. Go to the [Azure Certified Device portal](https://certify.azure.com).

-1. Select `Company profile` on the left-hand side and update your manufacturer information.

- 

-1. Accept the program agreement to begin your project.

-## Creating your project on the portal

-Now that you're all set up in the portal, you can begin the certification process. First, you must create a project for your device.

-1. On the home screen, select `Create new project`. This will open a window to add basic device information in the next section.

- 

-## Identifying basic device information

-Then, you must supply basic device information. You can to edit this information later.

-1. Complete the fields requested under the `Basics` section. Refer to the table below for clarification regarding the **required** fields:

- | Fields | Description |

- ||-|

- | Project name | Internal name that will not be visible on the Azure Certified Device catalog |

- | Device name | Public name for your device |

- | Device type | Specification of Finished Product or Solution-Ready Developer Kit. For more information about the terminology, see [Certification glossary](./resources-glossary.md). |

- | Device class | Gateway, Sensor, or other. For more information about the terminology, see [Certification glossary](./resources-glossary.md). |

- | Device source code URL | Required if you are certifying a Solution-Ready Dev Kit, optional otherwise. URL must be to a GitHub location for your device code. |

- > [!Note]

- > If you are marketing a Microsoft service (e.g. Azure Sphere), please ensure that your device name adheres to Microsoft [branding guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks).

-1. Select the `Next` button to continue to the `Certifications` tab.

- 

-1. Specify which certification(s) you wish to achieve for your device.

-1. Select `Create` and the new project will be saved and visible in the home page of the portal.

- 

-1. Select on the Project name in the table. This will launch the project summary page where you can add and view other details about your device.

- 

-## Next steps

-You are now ready to add device details and test your device using our certification service. Advance to the next article to learn how to edit your device details.

-> [!div class="nextstepaction"]

-> [Tutorial: Adding device details](tutorial-02-adding-device-details.md)

-description: A step-by-step guide to add device details to your project on the Azure Certified Device portal

-# Tutorial: Add device details

-Now you've created your project for your device, and you're all set to begin the certification process! First, let's add your device details. These will include technical specifications that your customers will be able to view on the Azure Certified Device catalog and the marketing details that they will use to purchase once they've made a decision.

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Add device details using the Components and Dependencies features

-> * Upload a Get Started guide for your device

-> * Specify marketing details for customers to purchase your device

-> * Optionally identify any industry certifications

-## Prerequisites

-* You should be signed in and have a project for your device created on the [Azure Certified Device portal](https://certify.azure.com). For more information, view the [tutorial](tutorial-01-creating-your-project.md).

-* You should have a Get Started guide for your device in PDF format. We provide many Get Started templates for you to use, depending on both the certification program and your preferred language. The templates are available at our [Get started templates](https://aka.ms/GSTemplate "Get started templates") GitHub location.

-## Adding technical device details

-The first section of your project page, called 'Input device details', allows you to provide information on the core hardware capabilities of your device, such as device name, description, processor, operating system, connectivity options, hardware interfaces, industry protocols, physical dimensions, and more. While many of the fields are optional, most of this information will be made available to potential customers on the Azure Certified Device catalog if you choose to publish your device after it has been certified.

-1. Click `Add` in the 'Input device details' section on your project summary page to open the device details section. You will see six sections for you to complete.

-

-2. Review the information you previously provided when you created the project under the `Basics` tab.

-1. Review the certifications you are applying for with your device under the `Certifications` tab.

-1. Open the `Hardware` tab and add **at least** one discrete component that describes your device. You can also view our guidance on [component usage](how-to-using-the-components-feature.md).

-1. Click `Save`. You will then be able to edit your component device and add more advanced details.

-1. Add any relevant information regarding operating conditions (such as IP rating, operating temperature, or safety certification).

-

-7. List additional device details not captured by the component details under `Additional product details`.

-1. If you marked `Other` in any of the component fields or have a special circumstance you would like to flag with the Azure Certification team, leave a clarifying comment in the `Comments for reviewer` section.

-1. Open the `Software` tab and select **at least** one operating system.

-1. (**Required for Dev Kit devices** and highly recommended for all others) Select a level to indicate the expected set-up process to connect your device to Azure. If you select Level 2, you will be required to provide a link to the available software image.

-

-11. Use the `Dependencies` tab to list any dependencies if your device requires additional hardware or services to send data to Azure. You can also view our additional guidance for [listing dependencies](how-to-indirectly-connected-devices.md).

-1. Once you are satisfied with the information you've provided, you can use the `Review` tab for a read-only overview of the full set of device details that been entered.

-1. Click `Project summary` at the top of the page to return to your summary page.

-

-## Uploading a Get Started guide

-The Get Started guide is a PDF document to simplify the setup and configuration and management of your product. Its purpose is to make it simple for customers to connect and support devices on Azure using your device. As part of the certification process, we require our partners to provide **one** Get Started guide for their most relevant certification program.

-1. Double-check that you have provided all requested information in your Get Started guide PDF according to the supplied [templates](https://aka.ms/GSTemplate). The template that you use should be determined by the certification badge you are applying for. (For example, an IoT Plug and Play device will use the IoT Plug and Play template. Devices applying for *only* the Azure Certified Device baseline certification will use the Azure Certified Device template.)

-1. Click `Add` in the 'Get Started' guide section of the project summary page.

-

-2. Click 'Choose File' to upload your PDF.

-1. Review the document in the preview for formatting.

-1. Save your upload by clicking the 'Save' button.

-1. Click `Project summary` at the top of the page to return to your summary page.

-## Providing marketing details

-In this area, you will provide customer-ready marketing information for your device. These fields will be showcased on the Azure Certified Device catalog if you choose to publish your certified device.

-1. Click `Add` in the 'Add marketing details' section to open the marketing details page.

-

-1. Upload a product photo in JPEG or PNG format that will be used in the catalog.

-1. Write a short description of your device that will be displayed on the product description page of the catalog.

-1. Indicate geographic availability of your device.

-1. Provide a link to the manufacturer's marketing page for this device. This should be a link to a site that provides additional information about the device.

- > [!Note]

- > Please ensure all supplied URLs are valid or will be active at the time of publication following approval.*)

-1. Indicate up to three target industries that your device is optimized for.

-1. Provide information for up to five distributors of your device. This may include the manufacturer's own site.

- > [!Note]

- > If no distributor product page URL is supplied, then the `Shop` button on the catalog will default to the link supplied for `Distributor page`, which may not be specific to the device. Ideally, the distributor URL should lead to a specific page where a customer can purchase a device, but is not mandatory. If the distributor is the same as the manufacturer, this URL may be the same as the manufacturer's marketing page.*)

-1. Click `Save` to confirm your information.

-1. Click `Project summary` at the top of the page to return to your summary page.

-## Declaring additional industry certifications

-You can also promote additional industry certifications you may have received for your device. These certifications can help provide further clarity on the intended use of your device and will be searchable on the Azure Certified Device catalog.

-1. Click `Add` in the 'Provide industry certifications' section.

-1. Click `Add a certification`to select from a list of the common industry certification programs. If your product has achieved a certification not in our list, you can specify a custom string value by selecting `Other (please specify)`.

-1. Optionally provide a description or notes to the reviewer. However, these notes will not be publicly available to view on the catalog.

-1. Click `Save` to confirm your information.

-1. Click `Project summary` at the top of the page to return to your summary page.

-## Next steps

-Now you have completed the process of describing your device! This will help the Azure Certified Device review team and your customer better understand your product. Once you are satisfied with the information you've provided, you are now ready to move on to the testing phase of the certification process.

-> [!div class="nextstepaction"]

-> [Tutorial: Testing your device](tutorial-03-testing-your-device.md)

-description: A step-by-step guide to test you device with AICS service on the Azure Certified Device portal

-# Tutorial: Test and submit your device

-The next major phase of the certification process (though it can be completed before adding your device details) involves testing your device. Through the portal, you'll use the Azure IoT Certification Service (AICS) to demonstrate your device performance according to our certification requirements. Once you've successfully passed the testing phase, you'll then submit your device for final review and approval by the Azure Certification team!

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Connect your device to IoT Hub using Device Provisioning Service (DPS)

-> * Test your device according to your selected certification program(s)

-> * Submit your device for review by the Azure Certification team

-## Prerequisites

-## Connecting your device using DPS

-All certified devices are required to demonstrate the ability to connect to IoT Hub using DPS. The following steps walk you through how to successfully connect your device for testing on the portal.

-1. To begin the testing phase, select the `Connect & test` link on the project summary page:

- 

-1. Depending on the certification(s) selected, you'll see the required tests on the 'Connect & test' page. Review these to ensure that you're applying for the correct certification program.

- 

-1. Connect your device to IoT Hub using the Device Provisioning Service (DPS). DPS supports connectivity options of Symmetric keys, X.509 certification, and a Trusted Platform Module (TPM). This is required for all certifications.

- - *For more information on connecting your device to Azure IoT Hub with DPS, visit [Provisioning devices overview](../iot-dps/about-iot-dps.md "Device Provisioning Service overview").*

-

-1. If using symmetric keys, you'll then be asked to configure the DPS with the supplied DPS ID scope, Device ID, authentication key, and DPS endpoint. Otherwise, you will be asked to provide either X.509 certificate or endorsement key.

-1. After configuring your device with DPS, confirm the connection by clicking the `Connect` button at the bottom of the page. Upon successful connection, you can proceed to the testing phase by clicking the `Next` button.

- 

-## Testing your device

-Once you have successfully connected your device to AICS, you are now ready to run the certification tests specific to the certification program you are applying for.

-1. **For Azure Certified Device certification**: In the 'Select device capability' tab, you will review and select which tests you wish to run on your device.

-1. **For IoT Plug and Play certification**: Carefully review the parameters that will be checked during the test that you declared in your device model.

-1. **For Edge Managed certification**: No additional steps are required beyond demonstrating connectivity.

-1. Once you have completed the necessary preparations for the specified certification program, select `Next` to proceed to the 'Test' phase.

-1. Select `Run tests` on the page to begin running AICS with your device.

-1. Once you have received a notification that you have passed the tests, select `Finish` to return to your summary page.

-

-7. If you have additional questions or need troubleshooting assistance with AICS, visit our troubleshooting guide.

-> [!NOTE]

-> While you will be able to complete the online certification process for IoT Plug and Play and Edge Managed without having to submit your device for manual review, you may be contacted by a Azure Certified Device team member for further device validation beyond what is tested through our automation service.

-## Submitting your device for review

-Once you have completed all of the mandatory fields in the 'Device details' section and successfully passed the automated testing in the 'Connect & test' process, you can now notify the Azure Certified Device team that you are ready for certification review.

-1. select `Submit for review` on the project summary page:

- 

-1. Confirm your submission in the pop-up window. Once a device has been submitted, all device details will be read-only until editing is requested. (See [How to edit your device information after publishing](./how-to-edit-published-device.md).)

- 

-1. Once the project is submitted, the project summary page will indicate the project is `Under Certification Review` by the Azure Certification team:

- 

-1. Within 5-7 business days, expect an email response from the Azure Certification team to the address provided in your company profile regarding the status of your device submission.

- - Approved submission

- Once your project has been reviewed and approved, you will receive an email. The email will include a set of files including the Azure Certified Device badge, badge usage guidelines, and other information on how to amplify the message that your device is certified. Congratulations!

- - Pending submission

- In the case your project is not approved, you will be able to make changes to the project details and then resubmit the device for certification once ready. An email will be sent with information on why the project was not approved and steps to resubmit for certification.

-## Next steps

-Congratulations! Your device has now successfully passed all of the tests and has been approved through the Azure Certified Device program. You can now publish your device to our Azure Certified Device catalog, where customers can shop for your products with confidence in their performance with Azure.

-> [!div class="nextstepaction"]

-> [Tutorial: Publishing your device](tutorial-04-publishing-your-device.md)

-description: A step-by-step guide to publish your certified device to the Azure Certified Device catalog

-# Tutorial: Publish your device

-Congratulations on successfully certifying your device! Your product is joining an ecosystem of exceptional devices that work great with Azure. Now that your device has been certified, you can optionally publish your device details to the [Azure Certified Device catalog](https://devicecatalog.azure.com) for a world of customers to discover and buy.

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Publish your device to the Azure Certified Device catalog

-## Prerequisites

-## Publishing your device

-Publishing your device is a simple process that will help bring customers to your product from the Azure Certified Device catalog.

-1. To publish your device, click `Publish to Device Catalog` on the project summary page.

- 

-1. Confirm the publication in the pop-up window

- 

-1. You will receive notification to the email address in your company profile once the device has been processed the Azure Certified Device catalog.

-## Next steps

-Congratulations! Your certified device is now a part of the Azure Certified Device catalog, where customers can shop for your products with confidence in their performance with Azure! Thank you for being part of our ecosystem of certified IoT products. You will notice that your project page is now read-only. If you wish to make any updates to your device information, see our how-to guide.

-> [!div class="nextstepaction"]

-> [How to edit your published device](how-to-edit-published-device.md)

- install:

-With the ability to, connect your Azure AI services to Azure Communication Services, you can enable custom play functionality, using [Text-to-Speech](../../../../articles/cognitive-services/Speech-Service/text-to-speech.md) and [SSML](../../../../articles/cognitive-services/Speech-Service/speech-synthesis-markup.md) configuration, to play more customized and natural sounding audio to users. Through the Azure AI services connection, you can also use the Speech-To-Text service to incorporate recognition of voice responses that can be converted into actionable tasks through business logic in the application. These functions can be further enhanced through the ability to create custom models within Azure AI services that are bespoke to your domain and region, through the ability to choose which languages are spoken and recognized, custom voices and custom models built based on your experience.

-You will need to connect your Azure Communication Services resource with the Azure AI resource through the Azure portal. There are two ways you can accomplish this step:

-2. If system-assigned managed identity isn't enabled, you will need to enable it.

-The custom SIP header key must start with a mandatory ΓÇÿX-MS-Custom-ΓÇÖ prefix. The maximum length of a SIP header key is 64 chars, including the X-MS-Custom prefix. The maximum length of SIP header value is 256 chars. The same limitations apply when configuring the SIP headers on your SBC.

-For `size`, select a confidential VM size. For more information, see [supported confidential VM families](virtual-machine-solutions.md).

- i. For **Size**, select a VM size. For more information, see [supported confidential VM families](virtual-machine-solutions.md).

-The lift and shift offering uses [AMD SEV-SNP (GA)](virtual-machine-solutions.md) or [Intel TDX (preview)](tdx-confidential-vm-overview.md) to encrypt the entire memory of a VM. This allows customers to migrate their existing workloads to Azure confidential Compute without any code changes or performance degradation.

-description: Azure Confidential Computing offers multiple options for confidential virtual machines on AMD and Intel processors.

-# Azure Confidential VM options

-Azure offers multiple confidential VMs options leveraging Trusted Execution Environments (TEE) technologies from both AMD and Intel to harden the virtualization environment. These technologies enable you to provision confidential computing environments with excellent price-to-performance without code changes.

-AMD confidential VMs leverage [Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP)](https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf) which was introduced with 3rd Gen AMD EPYC™ processors. Intel confidential VMs use [Trust Domain Extensions (TDX)](https://www.intel.com/content/dam/develop/external/us/en/documents/tdx-whitepaper-v4.pdf) which was introduced with 4th Gen Intel® Xeon® processors.

-## Sizes

-You can create confidential VMs in the following size families:

-| Size Family | TEE | Description |

-| | | -- |

-| **DCasv5-series** | AMD SEV-SNP | General purpose CVM with remote storage. No local temporary disk. |

-| **DCesv5-series** | Intel TDX | General purpose CVM with remote storage. No local temporary disk. |

-| **DCadsv5-series** | AMD SEV-SNP | General purpose CVM with local temporary disk. |

-| **DCedsv5-series** | Intel TDX | General purpose CVM with local temporary disk. |

-| **ECasv5-series** | AMD SEV-SNP | Memory-optimized CVM with remote storage. No local temporary disk. |

-| **ECesv5-series** | Intel TDX | Memory-optimized CVM with remote storage. No local temporary disk. |

-| **ECadsv5-series** | AMD SEV-SNP | Memory-optimized CVM with local temporary disk. |

-| **ECedsv5-series** | Intel TDX | Memory-optimized CVM with local temporary disk. |

-> [!NOTE]

-> Memory-optimized confidential VMs offer double the ratio of memory per vCPU count.

-## Azure CLI commands

-You can use the [Azure CLI](/cli/azure/install-azure-cli) with your confidential VMs.

-To see a list of confidential VM sizes, run the following command. Replace `<vm-series>` with the series you want to use. The output shows information about available regions and availability zones.

-```azurecli-interactive

-vm_series='DCASv5'

-az vm list-skus \

- --size dc \

- --query "[?family=='standard${vm_series}Family'].{name:name,locations:locationInfo[0].location,AZ_a:locationInfo[0].zones[0],AZ_b:locationInfo[0].zones[1],AZ_c:locationInfo[0].zones[2]}" \

- --all \

- --output table

-```

-For a more detailed list, run the following command instead:

-```azurecli-interactive

-vm_series='DCASv5'

-az vm list-skus \

- --size dc \

- --query "[?family=='standard${vm_series}Family']"

-```

-## Deployment considerations

-Consider the following settings and choices before deploying confidential VMs.

-### Azure subscription

-To deploy a confidential VM instance, consider a [pay-as-you-go subscription](/azure/virtual-machines/linux/azure-hybrid-benefit-linux) or other purchase option. If you're using an [Azure free account](https://azure.microsoft.com/free/), the quota doesn't allow the appropriate number of Azure compute cores.

-You might need to increase the cores quota in your Azure subscription from the default value. Default limits vary depending on your subscription category. Your subscription might also limit the number of cores you can deploy in certain VM size families, including the confidential VM sizes.

-To request a quota increase, [open an online customer support request](../azure-portal/supportability/per-vm-quota-requests.md).

-If you have large-scale capacity needs, contact Azure Support. Azure quotas are credit limits, not capacity guarantees. You only incur charges for cores that you use.

-### Pricing

-For pricing options, see the [Linux Virtual Machines Pricing](https://azure.microsoft.com/pricing/details/virtual-machines/linux/).

-### Regional availability

-For availability information, see which [VM products are available by Azure region](https://azure.microsoft.com/global-infrastructure/services/?products=virtual-machines).

-### Resizing

-Confidential VMs run on specialized hardware, so you can only [resize confidential VM instances](confidential-vm-faq.yml#can-i-convert-a-dcasv5-ecasv5-cvm-into-a-dcesv5-ecesv5-cvm-or-a-dcesv5-ecesv5-cvm-into-a-dcasv5-ecasv5-cvm-) to other confidential sizes in the same region. For example, if you have a DCasv5-series VM, you can resize to another DCasv5-series instance or a DCesv5-series instance.

-It's not possible to resize a non-confidential VM to a confidential VM.

-### Guest Operating System Support

-OS images for confidential VMs have to meet certain security and compatibility requirements. Qualified images support the secure mounting, attestation, optional [confidential OS disk encryption](confidential-vm-overview.md#confidential-os-disk-encryption), and isolation from underlying cloud infrastructure. These images include:

-As we work to onboard more OS images with confidential OS disk encryption, there are various images available in early preview that can be tested. You can sign up below:

-For more information about supported and unsupported VM scenarios, see [support for generation 2 VMs on Azure](../virtual-machines/generation-2.md).

-### High availability and disaster recovery

-You're responsible for creating high availability and disaster recovery solutions for your confidential VMs. Planning for these scenarios helps minimize and avoid prolonged downtime.

-### Deployment with ARM templates

-Azure Resource Manager is the deployment and management service for Azure. You can:

-Make sure to specify the following properties for your VM in the parameters section (`parameters`):

-## Next steps

-> [!div class="nextstepaction"]

-> [Deploy a confidential VM from the Azure portal](quick-create-confidential-vm-portal.md)

-For more information see our [Confidential VM FAQ](confidential-vm-faq.yml).

-You can configure resiliency policies like retries and timeouts for the following outbound and inbound operation directions via a Dapr component:

-resource myPolicyDoc 'Microsoft.App/managedEnvironments/daprComponents/resiliencyPolicies@2023-08-01-preview' = {

- }

- }

-resource myPolicyDoc 'Microsoft.App/containerApps/resiliencyPolicies@2023-08-01-preview' = {

-| SLA covers cloud platform | Yes | "Services, hardware, or software provided by a third party, such as cloud platform services on which MongoDB Atlas runs are not covered" |

-| Free tier | [1,000 request units (RUs) and 25 GB storage forever](../try-free.md). Prevents you from exceeding limits if you want | Yes, with 512 MB storage |

-You can add and remove regions to your Azure Cosmos DB account at any time. The throughput that you configure for various Azure Cosmos DB databases and containers is reserved in each region associated with your account. If the throughput provisioned per hour, that is the sum of RU/s configured across all the databases and containers for your Azure Cosmos DB account is `T` and the number of Azure regions associated with your database account is `N`, then the total provisioned throughput for your Azure Cosmos DB account, for a given hour is equal to `T x N RU/s`.

-Provisioned throughput with single write region costs $0.008/hour per 100 RU/s and provisioned throughput with multiple writable regions costs $0.016/per hour per 100 RU/s. To learn more, see Azure Cosmos DB [Pricing page](https://azure.microsoft.com/pricing/details/cosmos-db/).

-In a multi-region writes system, the net available RUs for write operations increases `N` times where `N` is the number of write regions. Unlike single region writes, every region is now writable and supports conflict resolution. From the cost planning point of view, to perform `M` RU/s worth of writes worldwide, you will need to provision M `RUs` at a container or database level. You can then add as many regions as you would like and use them for writes to perform `M` RU worth of worldwide writes.

-Consider that you have a container in West US configured for single-region writes, provisioned with throughput of 10K RU/s, storing 0.5 TB of data this month. LetΓÇÖs assume you add a region, East US, with the same storage and throughput and you want the ability to write to the containers in both the regions from your app. Your new total monthly bill (assuming 730 hours in a month) will be as follows:

-|**Item**|**Usage (monthly)**|**Rate**|**Monthly Cost**|

-|-|-|-|-|

-|Throughput bill for container in West US (single write region) |10K RU/s * 730 hours |$0.008 per 100 RU/s per hour |$584 |

-|Throughput bill for container in 2 regions - West US & East US (multiple write regions) |2 * 10K RU/s * 730 hours |$0.016 per 100 RU/s per hour |$2,336 |

-|Storage bill for container in West US |0.5 TB (or 512 GB) |$0.25/GB |$128 |

-|Storage bill for container in 2 regions - West US & East US |2 * 0.5 TB (or 1,024 GB) |$0.25/GB |$256 |

-If you have inefficient utilization, for example, one or more under-utilized read regions you can take steps to make the maximum use of the RUs in read regions by using change feed from the read-region or move it to another secondary if over-utilized. You will need to ensure you optimize provisioned throughput (RUs) in the write region first. Writes cost more than reads unless very large queries so maintaining even utilization can be challenging. Overall, monitor the consumed throughput in your regions and add or remove regions on demand to scale your read and write throughput, making to sure understand the impact to latency for any apps that are deployed in the same region.

-## Next steps

-Next you can proceed to learn more about cost optimization in Azure Cosmos DB with the following articles:

-* Learn more about [Optimizing for development and testing](optimize-dev-test.md)

-* Learn more about [Understanding your Azure Cosmos DB bill](understand-your-bill.md)

-* Learn more about [Optimizing throughput cost](optimize-cost-throughput.md)

-* Learn more about [Optimizing storage cost](optimize-cost-storage.md)

-* Learn more about [Optimizing the cost of reads and writes](optimize-cost-reads-writes.md)

-* Learn more about [Optimizing the cost of queries](./optimize-cost-reads-writes.md)

-* Trying to do capacity planning for a migration to Azure Cosmos DB? You can use information about your existing database cluster for capacity planning.

- * If all you know is the number of vcores and servers in your existing database cluster, read about [estimating request units using vCores or vCPUs](convert-vcore-to-request-unit.md)

- * If you know typical request rates for your current database workload, read about [estimating request units using Azure Cosmos DB capacity planner](estimate-ru-with-capacity-planner.md)

-| xxxxxxxx-xxxx- xxxx - xxxx -xxxxxxxxxxx | Reservations | Purchase | 15 | 120 | 0.8 | 120 | 1 hour | 1800 | Manual calculation of the actual charge: multiply 15 \* 120 \* 1 hour. |

-> - For EA customers `PayGPrice` isn't populated when `PricingModel` = `Reservations`, `Spot`, `Marketplace`, or `SavingsPlan`.

-> - For MCA customers, `PayGPrice` isn't populated when `PricingModel` = `Reservations`, `Spot`, or `Marketplace`.

-> - For EA customers, `UnitPrice` isn't populated when `PricingModel` = `Spot`, or `MarketPlace`.

-> - For MCA customers, `UnitPrice` isn't populated when `PricingModel` = `Reservations`, `Spot`, or `SavingsPlan`.

-> Microsoft no longer updates the Azure Enterprise Reporting APIs. Instead, you should use Cost Management APIs. To learn more, see [Migrate from Azure Enterprise Reporting to Microsoft Cost Management APIs overview](../automate/migrate-ea-reporting-arm-apis-overview.md).

-If you're exchanging for a different size, series, region or payment frequency, the term is reset for the new reservation.

-For customers that pay by credit card, the refunded amount is returned to the credit card that was used for the original purchase. If you've changed your card, [contact support](https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/newsupportrequest).

-The original reservation purchase invoice is canceled and then a new invoice is created for the refund. For exchanges, the new invoice shows the refund and the new purchase. The refund amount is adjusted against the purchase. If you only refunded a reservation, then the prorated amount stays with Microsoft and it's adjusted against a future reservation purchase. If you bought a reservation at pay-as-you-go rates and later move to a CSP, the reservation can be returned and repurchased without a penalty.

-The original invoice is canceled, and a new invoice is created. The money is refunded to the credit card that was used for the original purchase. If you've changed your card, [contact support](https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/newsupportrequest).

- - [Understand reservation usage for your Pay-As-You-Go subscription](understand-reserved-instance-usage.md)

- - Partner Center Action Center emails are sent to partners. For more information about how partners can update their transactional notifications, see [Action Center preferences](/partner-center/action-center-overview#preferences).

-4. On the given resource, go to **Networking** -> **Private endpoint connection** to approve it. The private endpoint is named as `data_factory_name.your_defined_private_endpoint_name` with description as "Requested by data_factory_name".

-description: This article shows you how to make a custom tenant and billing profile for educators in your organization

-This article is meant for IT Admins utilizing Azure for Classroom. When signing up for this offer, you should already have a tenant and billing profile created, but this article is meant to help walk you through how to create a custom tenant and billing profile and associate them with an educator.

-This section walks you through how to create a new tenant and associate it with your university tenant using multi-tenant

-4. After the tenant has been created copy the Tenant ID of the new tenant

-2. After the Educator has joined the tenant, go into the tenant properties and click Yes under the Access management for Azure resources.

-For more information, see quotas and limits for [namespaces](quotas-limits.md#namespace-resource-limits).

-| ThrottleType | The type of throttle limit that got exceeded in the namespace. The available values include: <br>- InboundBandwidthPerNamespace <br>- InboundBandwidthPerConnection <br>- IncomingPublishPacketsPerNamespace <br>- IncomingPublishPacketsPerConnection <br>- OutboundPublishPacketsPerNamespace <br>- OutboundPublishPacketsPerConnection <br>- OutboundBandwidthPerNamespace <br>- OutboundBandwidthPerConnection <br>- SubscribeOperationsPerNamespace <br>- SubscribeOperationsPerConnection <br>- ConnectPacketsPerNamespace <br><br>[Learn more about the limits](quotas-limits.md#mqtt-limits-in-namespace). |

-description: In this quickstart, you use Azure CLI to create an Azure Policy assignment to identify non-compliant resources.

-# Quickstart: Create a policy assignment to identify non-compliant resources with Azure CLI

-The first step in understanding compliance in Azure is to identify the status of your resources.

-This quickstart steps you through the process of creating a policy assignment to identify virtual

-machines that aren't using managed disks.

-At the end of this process, you'll successfully identify virtual machines that aren't using managed

-disks. They're _non-compliant_ with the policy assignment.

-Azure CLI is used to create and manage Azure resources from the command line or in scripts. This

-guide uses Azure CLI to create a policy assignment and to identify non-compliant resources in your

-Azure environment.

- account before you begin.

- `az --version`. If you need to install or upgrade, see

- [Install Azure CLI](/cli/azure/install-azure-cli).

- provider makes sure that your subscription works with it. To register a resource provider, you

- must have permission to the register resource provider operation. This operation is included in

- the Contributor and Owner roles. Run the following command to register the resource provider:

- ```azurecli-interactive

- az provider register --namespace 'Microsoft.PolicyInsights'

- ```

- For more information about registering and viewing resource providers, see

- [Resource Providers and Types](../../azure-resource-manager/management/resource-providers-and-types.md)

- tool that sends HTTP requests to Azure Resource Manager-based APIs.

-## Create a policy assignment

-In this quickstart, you create a policy assignment and assign the **Audit VMs that do not use

-managed disks** definition. This policy definition identifies resources that aren't compliant to the

-conditions set in the policy definition.

-Run the following command to create a policy assignment:

-```azurecli-interactive

-az policy assignment create --name 'audit-vm-manageddisks' --display-name 'Audit VMs without managed disks Assignment' --scope '<scope>' --policy '<policy definition ID>'

-The preceding command uses the following information:

- without managed disks Assignment_.

- this case, it's the ID of policy definition _Audit VMs that do not use managed disks_. To get the

- policy definition ID, run this command:

- `az policy definition list --query "[?displayName=='Audit VMs that do not use managed disks']"`

- enforced on. It could range from a subscription to resource groups. Be sure to replace

- &lt;scope&gt; with the name of your resource group.

-## Identify non-compliant resources

-To view the resources that aren't compliant under this new assignment, get the policy assignment ID

-by running the following commands:

-```azurecli-interactive

-az policy assignment list --query "[?displayName=='Audit VMs without managed disks Assignment'].id"

-For more information about policy assignment IDs, see

-[az policy assignment](/cli/azure/policy/assignment).

-Next, run the following command to get the resource IDs of the non-compliant resources that are

-output into a JSON file:

-```console

-armclient post "/subscriptions/<subscriptionID>/resourceGroups/<rgName>/providers/Microsoft.PolicyInsights/policyStates/latest/queryResults?api-version=2019-10-01&$filter=IsCompliant eq false and PolicyAssignmentId eq '<policyAssignmentID>'&$apply=groupby((ResourceId))" > <json file to direct the output with the resource IDs into>

-Your results resemble the following example:

-```json

-{

- "@odata.context": "https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.PolicyInsights/policyStates/$metadata#latest",

- "@odata.count": 3,

- "value": [{

- "@odata.id": null,

- "@odata.context": "https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.PolicyInsights/policyStates/$metadata#latest/$entity",

- "ResourceId": "/subscriptions/<subscriptionId>/resourcegroups/<rgname>/providers/microsoft.compute/virtualmachines/<virtualmachineId>"

- },

- {

- "@odata.id": null,

- "@odata.context": "https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.PolicyInsights/policyStates/$metadata#latest/$entity",

- "ResourceId": "/subscriptions/<subscriptionId>/resourcegroups/<rgname>/providers/microsoft.compute/virtualmachines/<virtualmachine2Id>"

- },

- {

- "@odata.id": null,

- "@odata.context": "https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.PolicyInsights/policyStates/$metadata#latest/$entity",

- "ResourceId": "/subscriptions/<subscriptionName>/resourcegroups/<rgname>/providers/microsoft.compute/virtualmachines/<virtualmachine3ID>"

- }

- ]

-}

-The results are comparable to what you'd typically see listed under **Non-compliant resources** in

-the Azure portal view.

-To remove the assignment created, use the following command:

-```azurecli-interactive

-az policy assignment delete --name 'audit-vm-manageddisks' --scope '/subscriptions/<subscriptionID>/<resourceGroupName>'

-To learn more about assigning policies to validate that new resources are compliant, continue to the

-tutorial for:

-> [Creating and managing policies](./tutorials/create-and-manage.md)

-|[Azure Databricks Workspaces should disable public network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0e7849de-b939-4c50-ab48-fc6b0f5eeba2) |Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can control exposure of your resources by creating private endpoints instead. Learn more at: [https://learn.microsoft.com/azure/databricks/administration-guide/cloud-configurations/azure/private-link](/azure/databricks/administration-guide/cloud-configurations/azure/private-link). |Audit, Deny, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Databricks/Databricks_AuditPublicNetworkAccess.json) |

-|[\[Preview\]: Certificates should have the specified maximum validity period](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0a075868-4c26-42ef-914c-5bc007359560) |Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. |audit, Audit, deny, Deny, disabled, Disabled |[2.2.0-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Certificates_ValidityPeriod.json) |

-|[Machines should be configured to periodically check for missing system updates](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fbd876905-5b84-4f73-ab2d-2e7a7c4568d9) |To ensure periodic assessments for missing system updates are triggered automatically every 24 hours, the AssessmentMode property should be set to 'AutomaticByPlatform'. Learn more about AssessmentMode property for Windows: [https://aka.ms/computevm-windowspatchassessmentmode,](https://aka.ms/computevm-windowspatchassessmentmode,) for Linux: [https://aka.ms/computevm-linuxpatchassessmentmode](https://aka.ms/computevm-linuxpatchassessmentmode). |Audit, Deny, Disabled |[3.5.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Update%20Manager/AzUpdateMgmtCenter_AutoAssessmentMode_Audit.json) |

-### Flaw Remediation

-**ID**: CCCS SI-2

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-|[Machines should be configured to periodically check for missing system updates](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fbd876905-5b84-4f73-ab2d-2e7a7c4568d9) |To ensure periodic assessments for missing system updates are triggered automatically every 24 hours, the AssessmentMode property should be set to 'AutomaticByPlatform'. Learn more about AssessmentMode property for Windows: [https://aka.ms/computevm-windowspatchassessmentmode,](https://aka.ms/computevm-windowspatchassessmentmode,) for Linux: [https://aka.ms/computevm-linuxpatchassessmentmode](https://aka.ms/computevm-linuxpatchassessmentmode). |Audit, Deny, Disabled |[3.5.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Update%20Manager/AzUpdateMgmtCenter_AutoAssessmentMode_Audit.json) |

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-|[\[Preview\]: Azure Key Vault should use RBAC permission model](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F12d4fa5e-1f9f-4c21-97a9-b99b3c6611b5) |Enable RBAC permission model across Key Vaults. Learn more at: [https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-migration](../../../key-vault/general/rbac-migration.md) |Audit, Deny, Disabled |[1.0.0-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVault_Should_Use_RBAC.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-### Permitted Actions Without Identification Or

-Authentication

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-### Audit And Accountability Policy And

-Procedures

-### Security Assessment And Authorization

-Policy And Procedures

-### Identification And Authentication

-(Organizational Users)

-|[\[Preview\]: Certificates should have the specified maximum validity period](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0a075868-4c26-42ef-914c-5bc007359560) |Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. |audit, Audit, deny, Deny, disabled, Disabled |[2.2.0-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Certificates_ValidityPeriod.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[\[Preview\]: Certificates should have the specified maximum validity period](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0a075868-4c26-42ef-914c-5bc007359560) |Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. |audit, Audit, deny, Deny, disabled, Disabled |[2.2.0-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Certificates_ValidityPeriod.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Azure Databricks Workspaces should disable public network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0e7849de-b939-4c50-ab48-fc6b0f5eeba2) |Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can control exposure of your resources by creating private endpoints instead. Learn more at: [https://learn.microsoft.com/azure/databricks/administration-guide/cloud-configurations/azure/private-link](/azure/databricks/administration-guide/cloud-configurations/azure/private-link). |Audit, Deny, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Databricks/Databricks_AuditPublicNetworkAccess.json) |

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-### Identification And Authentication

-(Organizational Users)

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |