Technical Migration Guide

> for internal application teams

⚠️ Using the Portal to migrate? View the Portal Migration Guide for a complete walkthrough.

📖 Learn More about the strategic reasons and business value of migrating, who can start now, and support changes to expect.

This guide offers a technical overview of the IDaaS migration process, tailored from the perspective of the migration team. It outlines the migration process, details the supporting tools and systems involved, and provides an overview to relevant links, forms, and support resources.

Application Migration Readiness

All non-production application environments (e.g., dev, test, QA, user acceptance testing (UAT) and stage) should be planned for onboarding (integration or migration) first. Once all non-production environments of the app have been integrated or migrated and successfully tested, then the production app can be onboarded to production.

Any application that fits into the following technical criteria can be considered for onboarding to Entra ID:

• applications that use OAuth 2.0, WS-Federation (WS-Fed), SAML 2.0, or SCIM as the authentication/authorization protocol
• applications that do not have a requirement for external client federations.

Please confirm that you have the necessary information about your application to begin raising SNow migration tickets.

Migration Flows and Dependencies

As of September 2025, there are some dependencies that need to be resolved before the migration can take place. Follow the flow chart below to determine if these apply to your application.

Determine if your application within PwC Identity (ForgeRock) today is making LDAP calls to Directory Services (OpenDJ) via an LDAP client. These can be in addition with their SSO integration or can be direct calls to LDAP.

Core Concepts

Entra ID tenants in PwC

Listed below are the Entra ID production tenant details:

• Tenant name: PwC
• Primary domain: PwC.onmicrosoft.com
• Tenant ID: 513294a0-3e20-41b2-a970-6d30bf1546fa
• Login URL: https://portal.azure.com/513294a0-3e20-41b2-a970-6d30bf1546fa

For your non-production environments, the following Entra ID tenants are available:

Tenant Name	PwC Staging	DevPwC365
Tenant ID	831f8b7b-7bbc-4d34-a62b-7baf9792d24a	d4093791-9818-48dc-8880-35d134b8c79d
Login URL	https://portal.azure.com/831f8b7b-7bbc-4d34-a62b-7baf9792d24a	https://portal.azure.com/d4093791-9818-48dc-8880-35d134b8c79d
Non-Admin Account format	john.smith@testenv.pwc.com	john.smith@dev365.pwc.com
Admin Account format	john.smith@admin.pwc.com	john.smith@admin.pwc.com

Migration Considerations

Note the following before planning your app's migration to Entra ID:

1. Stage and Dev have different email domains from "pwc.com" − make sure you have the right user with the correct email domain added to your test application. For example, the Stage environment has its own email domain name called "testenv.pwc.com" and the Dev environment has its own email domain called "dev365.pwc.com.

2. If you want to conduct a PoC for net-new application integrations, you can request to onboard your application to the Entra ID Dev tenant. Follow the steps listed below to request a dev365.pwc.com account. You will need to submit a general support ticket via SNow requesting account creation.

   • In the Short description field, state the following: Need a dev365.pwc.com account.
   • In the Enter details of your request... field, mention the following: "This request should be routed to 'Global - TSO - MS - L2' for fulfillment of a dev365 account with an E3 license."
     
     You may also specify the user's @pwc.com email address.

3. The Dev tenant is generally used for PoC's for net-new application integrations.

4. The Stage tenant is used to integrate the lower environments − Stage, Test, Dev, UAT and QA − for net-new applications and migration of existing applications from PwC ID

PwCID (ForgeRock) vs Entra ID Parity

While planning app migration to Entra ID, please note both the overall feature differences between the legacy and go-forward platforms, and specific technical support changes to account for, where applicable.

Identity Types: Internal & External

All of the tenants are set up to support both internal (i.e., PwC users) and external users (i.e., guest users).

For external users, the authentication method depends on the type of external user. There are three types of external users:

• Business to Business (B2B) guest users: External users with their own Entra tenants; authentication will happen on their own tenant.
• Federated guest users: External users with federated domains using a non-Entra Identity Provider (IdP) service (e.g., Active Directory Federated Services/Web Application Firewall [ADFS/WAP], Okta, PingFederate). Authentication will be handled by their respective IdPs.
• Individual guest accounts: Guest users will use email a One Time Password (OTP) sent by PwC Entra ID for authentication. These guest accounts do not have Entra ID tenant, nor do they support direct federation (e.g., Gmail or Yahoo users). Once these external users have been invited to the PwC Entra tenant and have been assigned access to the application, the authentication method may vary based on the type of external user. For guest accounts, we recommend using MFA. For B2B users, MFA is defined as their home tenant. For federated and individual guest accounts, we can apply MFA using Conditional Access Policy (CAP) in the PwC Entra tenant.

LDAP-Dependent Applications

This section applies to applications within PwC Identity (ForgeRock) that are making LDAP calls to Directory Services (OpenDJ) via an LDAP client.

The recommended option for ALL applications, including applications currently performing LDAP calls to ForgeRock OpenDJ, is to migrate to Entra ID via one or more of the options listed below:

1. Token claims − Update application code/configuration to use another protocol (SAML, OAuth/OIDC) to authenticate or obtain user information using tokens.

2. Graph API − Switch to the Graph API in instances where tokens do not provide the required information.

3. Perform LDAP calls to One AD − Leverage the existing One AD directory as an LDAP source (applicable to applications that only support internal PwC users).

Below is a high-level flow of the options.

Token Claims

If your application only needs to query/look up details about the authenticated user (i.e., the user using the application), then this information can be retrieved via token claims. If your application needs to retrieve information about users other than the individual using the application, another option will have to be implemented.

Graph API

If your application has the ability to make REpresentational State Transfer (REST) calls to retrieve user information, you can use the Microsoft Graph API to retrieve user information.

• You will need to request a non-personal (service) account with Entra ID - follow this guidance for proper form submission.
• Please request your service account as soon as you submit your SNow migration request.
• You will need to request the required Graph API permissions (delegated and/or application level). This process involves working with the M365 team. Please refer to the Microsoft 365 add-ons and third-party applications SharePoint site for detailed guidance on how to engage with the M365 team.
  • Refer to Microsoft Graph API Usage Guidelines for Graph API usage guidance.
  • Refer to MS Graph API Approval Matrix for a detailed breakdown of all Graph API permissions and notes about which APIs scopes are authorised for use and which require additional security approvals.

• Once you have obtained the necessary permissions, you will need to update your application code. Please refer to the following link to learn more about Microsoft APIs: https://developer.microsoft.com/en-us/graph/graph-explorer.

• Refer to our Entra guidance for transitioning from LDAP to Graph API for detailed information on how to transition from LDAP to Graph API.

Perform LDAP calls to One AD

If your application does not support token claims, cannot refactor to use Graph API and must use LDAP and ONLY has internal users, you have the option of switching the LDAP calls from ForgeRock OpenDJ to One AD.

• You will need to request a non-personal (service) account with Entra ID - follow this guidance for proper form submission.
• Once the service account has been created, update your code/configuration to make the necessary switch to use One AD LDAP.
• Review LDAP Migration Guidance (OpenDJ to OneAD) for details on how to complete a migration from OpenDJ to One AD.

If your application does not support any of the above options, you will have to engage the Identity team (i.e. engineering/architecture), as well as your application stakeholders (e.g., architects, SMEs) to seek an alternative solution to move forward. Engage the Identity team by sending an email to: gbl_idaas_team@pwc.com.

warning

If you are using the GUM API for external user management, this approach does not apply to you; your application will be included in a later migration wave.

Support Queues for Relevant Flows

#	Flow/usage	Support teams/SNow group	Team email address for questions or issues
1	Token claims	GLOBAL - NIS - IDENTITY AND ACCESS MANAGEMENT - APPLICATION INTEGRATION GLOBAL - NIS - IDENTITY AND ACCESS MANAGEMENT - ENTRA ID MIGRATION TEAM SNow link	us_gbl-nis-integration@pwc.com
2	Service accounts calling Graph API	GLOBAL - NIS - IDENTITY AND ACCESS MANAGEMENT - ENTRA ID MIGRATION TEAM SNow link	us_gbl-nis-integration@pwc.com
3	Service accounts using LDAP to call OneAD	GLOBAL - NIS – ID/ENTITY AND ACCESS MANAGEMENT - ONE AD OPERATIONS SNow link	gbl_nis-global-active-directory-operations@pwc.com

MFA in Entra

Refer to the Multi-Factor Authentication article for complete details

Entra ID Migration Checklist

The following checklists will walk you through some of the migration prerequisites and requirements and provide you with links to resources to help you through the process.

1. For app migrations, ensure you have a CI and ARR for your app. If your application has an ARR in any of the following statuses – approved, completed, completed with conditions, or completed with validations – it can migrate from ForgeRock to Entra ID's stage and production environments. If your application does not have an ARR or the ARR is in-progress, it cannot migrate from ForgeRock to Entra ID's stage or production environments.

2. Raise a request for an Admin(z) account for app owners for the stage and production tenants. This account will be used to give ownership of the application and can be used for app administration tasks. Please review the Entra ID New Admin(z) Account Guide. You can raise a request for an Admin(z) account in ServiceNow.

3. Confirm if you need to restrict application access to one or more groups of users. If you do, please create an Entra ID group for access restriction (this can be a new or an existing group). Please review the guidance on how to create an Entra ID group in the Entra ID Access Group Restrictions document.

4. Make a backup of the current PwC ID configuration code of your application (e.g., PwC ID Entity ID, ACS/Callback/Redirect URI/URLs, Claims, Authentication methods, IdP and Relying Party (RP) metadata and SSO URLs). This will need to be documented on the migration ticket raised in SNow so that the migration engineer can help ensure a parity post-migration to Entra ID.

5. Document any upstream or downstream dependencies that might be affected by the migration. Potential dependencies may include:

   • Mailbox provisioned to respond to app activation emails
   • Microsoft products such as Word, Excel, Power Platform or SharePoint Online licenses to execute business logic of the app
   • SaaS add-ons that will integrate with the app and Entra ID, to perform functions like identity lookups

6. If you are unsure, please request a technical consultation with the IDaaS Entra ID Migration team and bring your app design and architecture diagrams to review how the migration will affect these dependencies. To request this consultation, send an email to: gbl_idaas_team@pwc.com.

7. Confirm if you require Delegated API permissions only or Application API permissions if your application is for Open Authorisation (OAuth). If your application requires application API permissions, then you may need an M365 Global ARR, which is different from the ARR reviewed by the NIS team. Learn more about Delegated and Application API permissions here.

8. If the migrating app requires Application API permissions, please prepare an M365 ARR, which may take four to six weeks. The lack of a M365 Global ARR will not stop the integration or migration. However, for the integrated or migrated app to function as expected, the ARR needs to be completed, as only the M365 team has the privilege to grant those permissions.

9. Confirm if you will need admin consent for your application. Remember that while some delegate API permissions require admin consent, others do not. However, every application API permission does require admin consent. If your app requires a mix of delegate and application API permissions, then the admin consent can only be granted by the M365 team. It is important to make sure that an application is not under- or over-permissioned.

10. Access the IDaaS application migration portal to migrate your application from PwC Identity (ForgeRock) to MS Entra ID (if app has no LDAP or GUM API Dependencies)

11. Check if you require any security exceptions.

12. If you are unsure, please request a technical consultation with the IDaaS Entra ID Migration team and bring your app design and architecture diagrams to review how the migration will affect these dependencies. To request a consultation, send an email to: gbl_idaas_team@pwc.com

Staging Environment

Check with your vendor/developer to determine if there is a staging instance or environment for the application. If no staging environment exists for your app, you may integrate the production application into the Entra Staging tenant. Once the app is successfully tested on the staging tenant, it can be integrated into the production tenant.

OAuth 2.0 Applications

The OAuth+OIDC protocol supports several types of grant flows such as:

• Authorization Code Grant with and without PKCE
• Oauth 2.0 Resource Owner Password Credentials Grant
• Oauth 2.0 Client Credentials Grant
• Device Code Flow
• On-Behalf-of Flow

Implicit Grant Flow

PwC does not allow Implicit Grant flow in Entra ID due to well-documented security concerns. App teams migrating who currently use implicit grant must re-configure their apps to a more secure grant flow, such as the PwC-recommended Auth Code + PKCE flow.

Requirements

The following information is required from teams with OAuth 2.0 applications:

• App name: The name of the application.
• Application platform: This is the Single Page App, Web API/App, Mobile or Desktop/Native, Service/Daemon/Tasks the platform or app is developed for.
• Callback or redirect URL/URI/s: The URL/URI that the OAuth token will be sent to. Only Entra dev and stage tenants support localhost/loopback redirect URL/URIs if they are using HTTPS. On the Entra production tenant, localhost/loopback URIs are not supported, HTTPS or otherwise. HTTP URI/URLs are not supported by any tenant.
• Scopes: This refers to the permissions that are assigned to the app. By default, the integration & migration engineer will grant the following scopes and their admin consent to all OAuth apps:   - OpenID   - Profile   - Email   - User.Read

Additional considerations

• Unlike PwC ID, where you would need to provide your application's entity ID to be configured on the IdP side, the Entra app integration and migration engineer assigned to your Entra ID onboarding ticket will provide you with the application/client ID, which will be an alpha-numeric GUID. To accommodate this change, please confirm that you have reviewed and tested all downstream dependencies from the code change that will need to be made.

• If you have confirmed that your application needs Entra ID application API permissions and admin consent to those permissions, please ensure that before requesting the stage app migration, your ARR is completed and that you have allowed for the four-six week time frame that the M365 Engineering and Architecture team will need to review the request for the Entra Application API permissions and admin consent.

• The Entra ID app integration & migration engineer assigned to your migration ticket will perform the integration/migration of your application in Entra; once the M365 team has completed their review, they will assign the Entra Application API permissions and admin consent. The Entra ID app integration & migration engineer will not be able to assign these permissions and consent.

• By default, all OAuth grants are enabled in Entra ID except the Implicit Grant, which is disabled for security reasons. PwCID ForgeRock also disabled it for new apps and advised existing apps to move away from it. If you're migrating to Entra ID, switch to Authorization Code Grant or PKCE.

Please review Microsoft documentation on OAuth code samples, OAuth Application types, and Microsoft Graph for more information on Entra OAuth integration.

Endpoints

Following are the relevant endpoints for OAuth apps in Entra:

Authorization Endpoint

https://login.microsoftonline.com/{{Tenant_ID}}/v2.0/authorize

Token Endpoint

https://login.microsoftonline.com/{{Tenant_ID}}/v2.0/token

Logout Endpoint

https://login.microsoftonline.com/{{Tenant_ID}}/v2.0/logout

User Info Endpoint

https://graph.microsoft.com/oidc/userinfo

JWK URI

https://login.microsoftonline.com/{{Tenant_ID}}/discovery/v2.0/keys

Well Known OIDC metadata

https://login.microsoftonline.com/{{Tenant_ID}}/v2.0/.well-known/openid-configuration

Please make sure you have reviewed the following considerations while implementing the above endpoints in your code:

1. The {{Tenant_ID}} will be the tenant ID for the tenant that your application is integrated or migrated to, as described earlier:

Tenant	Tenant ID
Prod	513294a0-3e20-41b2-a970-6d30bf1546fa
Stage	831f8b7b-7bbc-4d34-a62b-7baf9792d24a
Dev	d4093791-9818-48dc-8880-35d134b8c79d

2. When initiating a logout, please make sure you follow the instructions documented here.

3. Consider using the ID token instead of calling the UserInfo endpoint, since ID token is a superset of the information available on UserInfo endpoint. Because you can get an ID token at the same time you get a token to call the UserInfo endpoint, we suggest getting the user's information from the token instead of calling the UserInfo endpoint. Using the ID token instead of calling the UserInfo endpoint eliminates up to two network requests, reducing latency in your application (Learn more).

4. Microsoft and PwC strongly recommend against hard coding these endpoints in your code and instead asks that you use the Microsoft Authentication Library (MSAL). For additional guidance and code samples, please refer to this document. If you cannot use MSAL, please choose OIDC certified library or comply with Microsoft SDL as described here.

5. Entra ID does not have an endpoint to decode or introspect JWT. To do this programmatically, you may use one of the libraries mentioned in the documentation above.

---

Scopes

By default, all migrating and integrating applications will be assigned the following permissions and granted admin consent to:

• Openid
  Provides an ID token, unique identifier for the 'sub' claim and access to the UserInfo endpoint.
• Profile
  Can be used with the openid scope and any other scope. It gives the app access to a large amount of information about the user. The information it can access includes, but not limited to, the user's given name, surname, preferred username, and object ID. For a complete list of the profile claims available in the id_tokens parameter for a specific user, see the id_tokens reference.
• Email
  Can be with the openid scope and any other scopes. It gives the app access to the user's primary email address in the form of the email claim. The email claim is included in a token only if an email address is associated with the user account, which isn't always the case. If your app uses the email scope, the app needs to be able to handle a case in which no email claim exists in the token.
• User.Read
  Allows the application to read the profile of the authenticating user.

All of the above-mentioned scopes/API permissions are provided as delegate permissions indicating authentication in user context. Since consent will be granted for these permissions at the tenant level, users will not be prompted to consent to these applications.

If your application requires application API permissions, then please review the Microsoft 365 Application Review Request process. If any additional scopes/API permissions are needed, please be sure to request the same when you raise a ticket. For more information on scopes, please read this document.

---

Claims

In Entra, OAuth applications can have three types of claims:

Claim Type	Description
Default Claims	Following documentation will give you the list of claims available in Access tokens and ID tokens.
Optional Claims	Please refer to this document for a list of optional claims available in Entra. Please be sure to look at the Token Type column and look at the claims with the value JWT.
Custom Claims	Please refer to this document for a list of attributes available in Entra ID that can be mapped to a custom claim of your choice, if the claims mentioned above do not meet your requirements.

⚠️ Restricted Claims: Microsoft restricts some claims from remapping or customization of any type.

Note

If your application requires any additional claims that is not available in the claims mentioned above, please engage the Application Integration and Migration team by raising a troubleshooting ticket.

---

Session Management

Unlike PwC ID, Entra ID does not have a maximum idle timeout or maximum session setting. Hence, to make re that your application times out an inactive user and renews the authenticated session at a frequency mandated by the ISP requirements, you will need to:

• Remove and revoke the application session cookies and cache
• Call the Entra ID logout URI mentioned above and
• initiate a fresh authentication session.

ISP Compliance Check

ISP security requirements are subject to change and you will need to confirm that the application code and configuration is updated to stay compliant.

---

Tokens

Token Duration:

Following is the default token lifetime in Entra ID. Please note that as of today, token duration is not customizable.

• Access token: A random value ranging between 60-90 minutes (75 minutes on average) - Learn More.
• ID Token: One hour - Learn More.
• Refresh Token: The default lifetime for the refresh tokens is 24 hours for single page apps and 90 days for all other scenarios - Learn More

Token Validation: Please review the following documents on how to validate:

• Access tokens
• ID tokens
• Claims

token duration, validation & sessions

---

SAML 2.0/WS-Fed Applications

Required SAML 2.0/WS-Fed information is provided below:

• Entity ID: This will uniquely identify a SAML app.

• Assertion Consumer Service (ACS) URI or WReply URL/URI: The URL/URI where the Entra will send the SAML token. PwC security policies require that Entra dev and stage tenants support localhost/loopback redirect URL/URIs if they are using HTTPS. On the Entra production tenant, localhost/loopback URIs are not supported, HTTPS or otherwise. HTTP URI/URLs are not supported by any tenant.

• NameID: This is the attribute that will uniquely identify the authenticating user.

• Claims: The attributes of the authenticating user that will be returned in the SAML token, including custom claims.

Optional Configuration

Optional configuration information like logout URI and Relay State URI can also be provided. To learn more, please review Entra ID SAML Single Sign On and SAML Single Log Out.

Endpoints

The following endpoints are relevant for SAML apps in Entra ID:

SAML Login & Logout endpoint

https://login.microsoftonline.com/{{Tenant_ID}}/saml2

WS-Fed Login & Logout endpoint

https://login.microsoftonline.com/{{Tenant_ID}}/wsfed

Federation Metadata endpoint

https://login.microsoftonline.com/{{Tenant_ID}}/2007-06/federationmetadata.xml

IdP-initiated sign-on endpoint

https://login.microsoftonline.com/{{Tenant_ID}}/federationmetadata/2007-06/federationmetadata.xml?appid={{Application_ID}}

1. The {{Tenant_ID}} will be the tenant ID for the tenant that your application is integrated or migrated to, as described in the section; "Entra ID tenants in PwC".

Tenant	Tenant ID
Prod	513294a0-3e20-41b2-a970-6d30bf1546fa
Stage	831f8b7b-7bbc-4d34-a62b-7baf9792d24a
Dev	d4093791-9818-48dc-8880-35d134b8c79d

2. The {{Application_ID}} will be provided to you by the migration technician, once the application has been onboarded.

3. When initiating a logout, please make sure you follow the instructions documented here.

4. When sending an authentication request, please confirm that RequestedAuthnContext is not included Learn More.

5. Microsoft and PwC strongly recommend against hard coding these endpoints in your code and instead asks that you use the Microsoft Authentication Library (MSAL). For additional guidance and code samples, please refer to this document. If you cannot use MSAL, please choose OIDC certified library or comply with Microsoft SDL as described here.

---

Claims

SAML and WS-Fed applications can request the following types of tokens:

Claim Type	Description
Default Claims	This article will provide you with the SAML claims that are issued by default.
Optional Claims	This articlewill provide you with the optional claims issued on a SAML token. Please be sure to look at the column Token Type and look at the claims with the value SAML.
Custom Claims	Please refer to this document for a list of attributes available in Entra ID that can be mapped to a custom claim of your choice, if the claims mentioned above do not meet your requirements.

⚠️ Restricted Claims: Microsoft restricts some claims from remapping or customization of any type.

Note

If your application requires any additional claims that is not available in the claims mentioned above, please engage the Application Integration and Migration team by raising a troubleshooting ticket.

Token Duration

The default SAML token lifetime is 1 hour. As of today, default token lifetimes cannot be customized. For more information, please click here.

Session Management

Unlike PwC ID, Entra does not have a maximum idle timeout or maximum session setting. Hence, to make sure your application times out an inactive user and renews the authenticated session at a frequency mandated by ISP requirements, you will need to:

• Purge the application session cookies and cache
• Call the Entra ID logout URI mentioned above and
• Initiate a fresh authentication session.

ISP Compliance Check

ISP security requirements are subject to change and you will need to confirm the application code and configuration is updated to stay compliant.

Entra ID application migration phases (SNow form)

Once the ticket is created from this SNow Application Integration Troubleshooting form, it is submitted to the IDaaS Entra ID Integration & Migration team. An Entra ID app migration engineer will be assigned to the ticket and will contact you to validate the information provided in the form.

If you need help drafting this form or if you wish to inquire about the status of a ticket, please reach out to us at: gbl_idaas_team@pwc.com.

An Entra ID app migration engineer may request clarification to confirm that they can proceed with the migration.

Phase 1: Migration

When the information in the form has been validated, the migration will be scheduled for the next available change window, and this is where your service level agreement (SLA) of four business days begins. This means that within the next four business days, you can expect the following configuration details from the Entra App Migration Engineer assigned to the ticket:

• Application/Client/Entity ID
• Client secret details (shared over Google Chat/MS teams to ensure it is not documented in plain text on any platform persistently; as instant messaging platforms will remove the conversation based on organization retention policies, please confirm timely and secure storage of these credentials)
• Token-signing certificate information
• Other datapoints, including: Authorization, token, federation metadata, Graph API, sign-in and sign-off/logout endpoints, and files from the respective Entra tenants

Phase 2: Migration validation & access management

Please ensure you have used your admin account to log in to the respective Entra tenant and validate the application registration and its properties. Please ask the Entra app migration engineer assigned to your ticket for help if needed after you have followed the process outlined in the Entra ID New Admin(z) Account Guide.

After confirming that you are able to view and manage the application registration properties, please confirm that you have reviewed the users and groups allowed to access the application. If needed, seek help from your Entra ID app migration engineer to add a user to the app, so that you may test the authentication for this app registration using IdP-initiated sign-in flow. If you want help on how to validate group ownership and membership, please refer to the following guidance:

• Search groups and members in Microsoft Entra ID
• Entra ID Access Group Restrictions

Phase 3: Cutover

After you have tested the authentication using the IdP-initiated flow (i.e., where you directly go to Entra and request an authentication instead of going to the application and then getting redirected to Entra), you are ready to share the configuration information that you received from your Entra app migration engineer in phase 1 of the migration with your developer/vendor team. This will enable your application to redirect your users to Entra instead of PwC ID, and confirm that the authentication, as well as any token-dependent business logic defined inside the app, is working as expected.

After you have tested the authentication using the IdP-initiated flow (i.e., where you directly go to Entra and request an authentication instead of going to the application and then getting redirected to Entra), you are ready to share the configuration information that you received from your Entra app migration engineer in phase 1 of the migration with your developer/vendor team. This will enable your application to redirect your users to Entra instead of PwC ID, and confirm that the authentication, as well as any token-dependent business logic defined inside the app, is working as expected.

If the authentication is not working as expected, please collect any error messages using screenshots and a Network trace and Fiddler trace using a new incognito browser and share those details with the Entra app migration engineer assigned to your ticket. This will help the engineer analyse the cause of the authentication failure and troubleshoot the issue.

Before advising users to try and access the application directly, ask them to log in to My Sign-Ins | Security info | Microsoft.com, download the Microsoft Authenticator app, and complete the registration process as documented in the Microsoft Authenticator Setup QRG.

Once the authentication has been tested successfully, please roll out communications to your users, asking them to test the application and monitor for feedback. Your Entra app migration engineer will stay engaged for two weeks on the same ticket; after that, you can request support by creating a new ticket from this SNow Application Integration Troubleshooting form.

Post-Integration & migration instructions

Once the integration and migration engineer has notified you of the completion of the integration or migration, please follow the steps below to validate the success of the onboarding effort to Entra ID. If you have questions or concerns, please engage your integration and migration engineer.

1. Ensure that users and groups that need to access the application have been added to the application. The app owner, who has been provided the admin(z) account, will be responsible for ensuring that those users that need to access the app are added to the application. If the app has multiple groups added, then the app owner will confirm that they can collaborate with all group owners to make sure those groups are up to date.

2. Share the Entra ID metadata and endpoint information provided by your integration and migration engineer with your application developer/vendor team and ask them to plan and schedule the redirect/cutover to Entra ID.

3. After the redirect/cutover is complete, test the authentication to Entra ID. Please engage your integration and migration engineer immediately if questions arise. Ensure any downstream dependencies/components that are dependent on the authentication are functioning as expected.

4. When all application testing is validated successfully, please ask your users to test the authentication and immediately report any issues.

5. Take note of expiration dates of client secrets and certificates for OAuth apps and token-signing certificates for SAML/WS-Fed apps, so that you can validate that they get renewed in a timely manner. Please review the Entra ID Client Secrets and Certificates Guide.

For Migrations Only

1. During the two-week hypercare phase, regularly communicate with your migration engineer to highlight any authentication or authorization issues.

2. If you are satisfied with the testing of your app on Entra, please communicate an authorization to disable the app integration on PwC ID. Please note, 30 days after the production application has been cutover successfully, we will disable the production and lower app integrations in PwC ID. If there is a need to rollback, you may reach out to us and/or raise a ticket to do so.

Application Self-Management Tasks

The table below outlines the recurring application self-management tasks for application and group owners.

No.	Task name	Frequency	Task owner	Documentation
1	Application Secrets & Certificates Management	Secrets: 12- 24 months Token-signing certificates: 36 months	Application owner using their admin(z) account	Entra ID Client Secrets and Certificates Guide
2	Add more app owners	As needed	Original app owner. Ownership permissions should be assigned only other admin(z) accounts. Non-admin accounts (pwc.com) accounts should not be used.	Entra ID New Admin(z) Account Guide
3	Application Access Management for users and groups	As needed	App owners(z) and group owners. App owners will need to ensure that the app is assigned to an updated list of users and groups. Group owners will need to ensure that the membership is current.	Entra ID Access Group Restrictions

note

Client secrets are recommended to be valid for one year, but they can be validated for up to two years. Token signing certificates are valid for three years by default, but custom certificates can be valid for various periods. Client certificates can be valid for any duration, as they are custom certificates and are not issued by Entra.

Appendix

Glossary

Term	Definition
Access group	Groups of users that can be used to restrict access to your group; can be created based on department, region or other category by using a naming convention that reflects the purpose or audience of the group (e.g., US-Sales-All).
ACS	Assertion Consumer Service
ADFS	Active Directory Federated Services
Admin account	This is usually someone from the application team who is delegated to perform several app management tasks, such as renewing certificates and secrets or adding owners, users or groups to the app.
API	Application Programme Interface
App integration	This is the process where the IAM team will create a trust between the IdP and the application using a configuration provided by the app team. Upon completion, the IAM team will provide metadata, endpoints, certificates and other IdP configuration information that the app team will need to upload to the app.
App migration	This is the process where the IAM team will create a copy of the application integration from PwC ID, in Entra ID, and the app team will replace the PwC ID configuration information with Entra ID configuration information. This will enable users to authenticate with Entra ID as opposed to PwC ID.
Application permissions	Application permissions are applied to those Entra apps that authenticate directly against Entra and there are no users authenticating. This type of permission is needed for background service, automations, daemons, etc. These permissions are also known as app roles. See more.
ARR	Application Readiness Review (NIS) or Application Review Request (M365)
Assigned group	An assigned group is a group in Entra where the member users and groups must be manually managed/added/removed by the group owners. This type of group can be created on GUM/One AD and synced to Entra or created directly in Entra. Anyone can create assigned groups in Entra by logging into https://mygroups.microsoft.com.
Authentication	Authentication is the process where a user or service proves or authenticates their identity to an IdP.
Authorisation	Authorisation is the process where an IdP verifies if the user is allowed to access the resource or application that they are trying to log in to.
B2B	Business to Business
BAU	Business As Usual
CAP	Conditional Access Policy
CBA	Certificate-Based Authentication
CI	Configuration Item
Delegated permissions	Delegated permissions are applied to Entra apps to allow the app to act on behalf of the authenticating user. These are needed for public apps that require an end user authentication. They are also known as scopes. See more.
Dynamic group	A dynamic group describes any group that does not require the manual addition/removal of users and other groups but does so automatically based on group membership rules as defined either during the creation of the group or modified later. Dynamic groups are to be created only on-premises (SailPoint) and then synced to Entra ID and should not be created directly in Entra ID.
Entra ID	Entra ID is the cloud-based IAM tool from Microsoft.
GUID	Global User ID
GUM	Global User Management (GUM) is the portal where PwC users can create/manage/delete internal as well as external users and groups.
IAM	Identity and Access Management
IDaaS	Identity as a Service
IdP	Identity Provider (IdP) refers to any product or service that is capable of authenticating, authorizing and federating trust between users and other applications within and outside the internal network. Entra, ForgeRock OpenAM, Okta are examples of Identity Providers.
KMSI	Keep Me Signed In
LDAP	Lightweight Directory Access Protocol
MFA	Multi-factor authentication
OAuth	Open Authorisation (OAuth) is an industry standard protocol used for authorisation. See more.
OTP	One Time Password
PoC	Proof of Concept
PwC ID	PwC Identity (PwC ID) is a term that usually refers to the PwC on-premises instance of ForgeRock OpenAM IdP service. See more.
RFC	Request for Change
RP	Relying Party or Resource Provider (RP) is the organisation that receives and processes claims; it typically references the application that the user is trying to authenticate with.
SaaS	Software as a Service
SAML	Security Assertion Markup Language (SAML) is an industry standard protocol for authentication. See more.
SCIM	System for Cross-Domain Identity Management (SCIM) is an open standard protocol for automating the exchange of user identity information between identity domains and IT systems. SCIM ensures that employees added to the Human Capital Management (HCM) system automatically have accounts created in Microsoft Entra ID or Windows Server Active Directory. User attributes and profiles are synchronized between the two systems, updating and removing users based on the user status or role change. See more.
Scopes	Scopes is also referred to as delegate permissions; these permissions are sent on the authentication request, and an access token will be issued by Entra only if these permissions are assigned to the migrated app on Entra.
SLA	Service Level Agreement
SNow	ServiceNow
SPA	Single Page App
SSO	Single Sign On (SSO) is the authentication process where the user is prompted for the username/email address, no more than once. This is done by re-using tokens cached on the user's PC or the browser to perform silent/non-interactive authentication in the background.
Static Group	A static group is the same as an assigned group. It is a group that can be added in GUM/One AD/Entra where the membership is manually managed by the group owner.
Token	A token is a document that is usually signed using certificates, and that contains sensitive authentication and/or authorisation information of the user, service, application, IdP and resource; it also contains details of the authenticated session and validity token.
WAP	Web Application Firewall
WS-Fed	Web Service Federation (WS-Fed) is an identity federation protocol that can be used for authentication and is supported by PwC ID and Entra ID. See more.

Additional Resources

Click here to review a complete list of Entra ID terms and definitions.

Resources

Listed below are links to internal documentation (i.e., created by PwC) and public documentation (i.e., created by Microsoft) for review by application teams and/or vendor teams in preparation for migration.

No.	Description	Documentation
1	To submit an Entra ID application migration request via SNow	IDaaS SNow Form Submission Guide for Entra ID Integrations & Migrations
2	To request an admin(z) account for owner to manage the application	Entra ID New Admin(z) Account Guide
3	To validate access groups for application access restrictions in Entra	Entra ID Access Group Restrictions
4	Link to the SharePoint site with information about the M365 Global application review request process for application API permissions	M365 Global application review requests
5	Guide for credentials management	Entra ID Client Secrets & Certificates Guide
6	Microsoft documents for application developer/vendor team to understand the Microsoft Identity Platform on which they need to build or update the application	What is Microsoft Entra ID?
		Microsoft identity platform documentation
		How the Microsoft identity platform uses the SAML protocol
		Microsoft identity platform and OAuth 2.0 authorization code flow
		Microsoft identity platform (OAuth) code samples
		Overview of the Microsoft Authentication Library (MSAL)
		Entra ID architecture overview
		Search groups and members in Microsoft Entra ID
7	Microsoft trust and reliability documentation	SLA performance for Microsoft Entra ID
		Recent worldwide SLA performance (99.999%)
		Microsoft Entra ID's backup authentication system
		Advancing reliability
		Microsoft Entra resilience update: Workload identity authentication

SNow links

Listed below are links to related SNow forms and email addresses of the teams that will be responsible to resolve tickets that are raised from these forms.

No.	SNow link	Distribution list email	Comments
1	Request migration of application from PwC ID to Entra ID	us_gbl-nis-integration@pwc.com and gbl_idaas_team@pwc.com	Please review this guide for instructions.
2	NIS ARR	gbl_nis_arr@pwc.com	SNow form to start the application readiness review process.
3	Register New Technology	N/A	SNow form for new technology registrations into the Configuration Management Database.
4	Microsoft 365 - Global Application Review Request	gbl_m365_architecture_review@pwc.com	Form used to request Entra Application API permissions and admin consent. Submit a request for review and approval of M365 applications and add-ins that access PwC's domain (i.e., pwc.com).
5	Application Integration Service	us_gbl-nis-integration@pwc.com	For any application that has been integrated or migrated to Entra, or if updates are required, please complete this form.
6	Request troubleshooting support for your migrated application	us_gbl-nis-integration@pwc.com	If you require troubleshooting support for your application after two weeks of hypercare.
7	Request to create a new assigned group in Entra ID	us_gbl-nis-integration@pwc.com	To request support for a new/existing static/assigned group in Entra ID.
8	Request changes to the static group in Entra ID	gbl_eam_access_management@pwc.com	If you require nested groups (i.e., group within group).
9	Request to create a dynamic group	gbl_nis-iam-tickets@pwc.com	To request the creation of a dynamic group that is created in SailPoint, synced to One AD and then Entra.
10	Request to sync static groups from GUM to Entra	gbl_eam_access_management@pwc.com	To request support for existing static/assigned groups in GUM.
11	Request to create a service account in Entra	gbl_eam_access_management@pwc.com	If Entra applications require a service account to be provisioned in Entra.
12	Request an admin account (Stage & Production Entra)	Production gbl_eam_access_management@pwc.com Stage gbl_nis-iam-tickets@pwc.com	To request an admin(z) account in Entra ID stage and production tenant. SNow form to create an Admin account in Azure, which is required to perform certain validations and updates on the application side.
13	Request an admin account (Dev Entra)	gbl_tso_ms_l2@pwc.com	To request an admin account on Dev 365.pwc.com to manage PoC applications in the Entra dev tenant.
14	Request to provision a user on Entra that is not already provisioned	gbl_eam_access_management@pwc.com	If users that should be on Entra cannot be found, this form can help you provision those users in Entra.
15	Request a new application to be integrated into Entra	us_gbl-nis-integration@pwc.com	If you have an application that is not integrated with PwC ID and needs to be integrated with Entra, complete this form.
16	Request a Conditional Access Policy (CAP) to allow access, block access or allow access with MFA for your app based on specific conditions	gbl_nis_azure_ad@pwc.com	If your application requires complex authentication policies based on conditions such as the authentication location or time, then you will need a conditional access policy to be applied to the app.