paulo-nascimento

Paulo Nascimento is a Machine Learning Engineer at Okta, spearheading AI development for the Customer Identity Cloud (CIC). He brings expertise from AI startups to create innovative solutions powering the CIC organization. Paulo's work focuses on integrating AI technologies to strengthen enterprise security, enhance user experience, and drive intelligent automation across Okta's identity platform.

Machine Learning Engineer

Paulo Nascimento

Waleed Manzoul

Staff Product Designer

Automate user lifecycle, enhance security and boost IT efficiency across your enterprise

## Introduction

Consider a Fortune 500 company, like a bank with 40,000 employees. A financial analyst at this company will use many SaaS tools to do their job, like Slack, Google Suite for Work, Zoom, Tableau, Workday, and more. In fact, enterprise organizations rely on [an average of 211 apps each](https://www.okta.com/businesses-at-work/) to run their businesses.

So, the bank’s central IT team might be responsible for managing 200+ SaaS apps, and our financial analyst may need access to a quarter of them. Naturally, for an employee to use all of those apps, accounts for each one would need to be provisioned first.

Fortunately, our bank’s IT team is smart. They utilize [Okta Workforce Identity Cloud](https://www.okta.com/workforce-identity/) to maintain [a directory of all their employees](https://www.okta.com/products/universal-directory/) and enable easy account creation and access to those SaaS apps using [Single Sign-On](https://auth0.com/docs/authenticate/single-sign-on). That means they don’t have to manually provision SaaS apps every time a new employee joins the company or an existing employee needs access.

But what about other events in an employee’s time with the company, such as when they change their role, change their name or pronouns, or eventually leave the company? How many times might those events happen over 40,000 employees? And how might each of those changes be reflected in the SaaS apps that they use?

## User Lifecycle Management Using SCIM

Fortunately, if a SaaS app used at the company relies on a workforce provisioning engine that utilizes SCIM ([System for Cross Identity Management](https://scim.cloud/), a standard for automating the exchange of user identity information between identity domains), that app can synchronize its user list to the central employee directory and react to changes that happen in the directory.

For the bank’s central IT team, this means they can make updates to users once in their central employee directory and have those changes reflected in all of the SaaS apps an employee uses, **reducing administrative overhead and toil**.

The power of this “live” connection that SCIM provides becomes critical when an employee leaves the company. Once central IT deletes this employee from their central directory, any user accounts they had with those SCIM-powered SaaS apps will be deactivated within seconds, **eliminating the chance of unauthorized access** through “[zombie accounts](https://www.wsj.com/tech/cybersecurity/unused-online-accounts-data-safety-38fa675e)” and **maintaining compliance with data privacy regulations**, like [GDPR](https://gdpr-info.eu/art-5-gdpr/).

Timely deprovisioning of former employees can have **cost savings** as well. When an employee leaves, the central IT team can quickly release the employee’s SaaS licenses and accurately reflect the reduced spend to the respective vendors.

So, you can imagine that the bank’s central IT team would want any new SaaS app it evaluates to leverage SCIM due to its many benefits:

* Saves a lot of manual labor
* Improves their security posture
* Saves their company money

## How Does SCIM Provisioning Work?

SCIM works by providing a defined schema of identity data that represents users and groups, along with a REST API that supports JSON and XML for CRUD operations on those user and group resources. 

Behind the scenes, SCIM is broken down into a few core components:

* SCIM Service Provider
    * This service hosts the identity data and responds to SCIM API requests. It’s also commonly called a SCIM server.
    * _Examples: Cloud applications, identity providers (e.g., Okta)_
* SCIM Client
    * The SCIM Client **initiates SCIM requests to interact with a SCIM server to perform operations that manage identities.**
    * _Examples: Identity management systems, HR systems_
* SCIM Schema
    * The SCIM schema defines the structure of identity data.
    * Core schemas: User, Group, EnterpriseUser (defined in [RFC7643](https://datatracker.ietf.org/doc/html/rfc7643))

The SCIM core components then use an HTTP-based REST API that supports JSON and XML data formats, although JSON is more common. The REST API uses standard HTTP methods like GET, POST, PUT, PATCH, and DELETE to support CRUD operations.

SCIM supports a number of key operations, such as:

* User Provisioning
    * The ”SCIM Client” sends a POST request to create a new user, and the ”SCIM Provider” creates the user and returns a unique identifier (ID).
* User Retrieval
    * The ”SCIM Client” sends a GET request with the user ID or search criteria, and the ”SCIM Provider” returns user data that matches the request, provided the user exists.
* User Update
    * The ”SCIM Client” sends a PUT or PATCH request with the updated user data, and the ”SCIM Provider” applies changes and confirms the update.
* User Deprovisioning
    * The ”SCIM Client” sends a DELETE request, and the ”SCIM Provider” removes or deactivates the user account.

On top of this core functionality, SCIM also provides useful features such as: 

* Bulk Operations
    * Where batch processing can be applied for multiple SCIM operations in a single request
* Filtering and Searching
    * Allows complex queries to find specific users or groups by using a standardized filter syntax

For each request, the SCIM REST API will return with the appropriate HTTP status to indicate success or failure along with detailed error messages for troubleshooting. SCIM typically uses OAuth 2.0 for authorization and supports HTTPS for secure data transmission.

SCIM is also extensible, which means that organizations can extend the standard SCIM schemas to accommodate their specific needs. For example, if an organization wants to include additional information about employees not covered by the standard SCIM schemas, then they can store additional information such as ”department” or ”manager” in their user profiles.

## SCIM vs SAML

Security Assertion Markup Language (SAML) is an XML-based framework for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). It’s most commonly used to enable Single Sign-On (SSO) across different web applications and services.

SCIM and SAML are both protocols for identity and access management (IAM). However, they serve different purposes. 

SCIM is used for user provisioning and management across different systems and applications, ensuring that identity data is consistent across. SAML, on the other hand, is used to access multiple applications with a single set of credentials.

> In summary, SCIM is for user management, while SAML is for user authentication.

## SCIM vs. SSO

Single Sign-On (SSO) is an authentication method that allows users to sign in to multiple applications with a single set of credentials.

Although SCIM and SSO are related, SCIM is a protocol used for provisioning appropriate roles and groups to users, whereas SSO authenticates those users into multiple accounts with a single set of login credentials.

## Inbound SCIM with Auth0

If you’ve been reading about SCIM online, you’ve probably found identity providers like Okta Workforce Identity Cloud and Microsoft Entra ID support SCIM in different ways, and that building for each of them can become a substantive effort. We’d advise that you learn about the identity providers your customers use and tailor your SCIM solution to meet the majority of your customers. However, If you think you will need to integrate your development with more than one identity provider, don't despair: there are solutions that allow you to easily connect to multiple identity providers at once. 

In fact, that's one of the things we do at Auth0. Our [Inbound SCIM solution](https://auth0.com/docs/authenticate/protocols/scim) allows you to integrate with Okta Workforce Identity Cloud, Microsoft Entra ID, and other identity providers via both SAML and OpenID Connect, manage attribute mappings on a per connection basis, and more. 

## Conclusion

SCIM is a powerful way to automate user lifecycles and maintain user accounts across platforms that can save companies time, money, and increase their security. Learn more about SCIM by exploring the [Auth0 docs](https://auth0.com/docs/authenticate/protocols/scim). 


Streamline Account Provisioning and Management with SCIM

pawan bhardwaj

Pawan is a seasoned business and technology enthusiast who welcomes challenges and pushes boundaries for value creation. In addition to his passion for technology, he also enjoys learning about music, art, architecture, and philosophy as lifelong pursuits.

In his career, he has worked in the domains of product management, solutions architecture, cybersecurity, cloud, telecom, and software engineering. He has led SaaS scaling initiatives in Cybersecurity (IAM), portfolio evolutions to cloud and telecom APIs, and deep partner engagements.

He has an MBA from Sonoma State University and an MS from the University of Delhi.

Principal Product Manager

Pawan Bhardwaj

jc tierney

JC Tierney was born and raised in the suburbs of Chicago, and is a life-long Blackhawks, White Sox and Bears fan.

He graduated from Benet Academy in Lisle, Illinois. He went on to attend the University of Dayton, where he graduated with a degree in Management Information Systems, and loved every minute of the experience.

Director, Engineering

JC Tierney

Efficiency on a robust foundation: Exploring multi-subscriber (Public Cloud) deployment on Auth0's converged platform architecture.

**TL;DR:** Auth0’s SaaS services are available via two modes of cloud deployment:

* Multi-subscriber (shared infrastructure, a.k.a. Public Cloud) 
* Single subscriber (dedicated infrastructure, a.k.a. Private Cloud). 

These offerings now have a converged platform architecture that increases business agility, developer productivity, scalability, reliability, and security by using industry-leading tools and fully automated operations.

This article continues a series of earlier ones focused on Private Cloud deployments. Unlike the single-subscriber Private Cloud, the Public Cloud hosts thousands of subscribers. In multi-subscriber deployments, data isolation, security, and elimination of noisy neighbor problems are paramount.

Public Cloud leverages the converged architecture composed of three tiers - the Central tier, Points of Presence (PoPs), and Spaces. The Central tier and PoPs are for control, operations, and shared services. Spaces are environments that provide customer identity services as per customers’ needs.

We leverage Kubernetes for lifecycle and runtime management of Auth0’s cloud-native containerized solution. Auth0 is composed of stateless services that are easier to scale. We use MongoDB, PostgreSQL, and Redis as required by the situation. We ensure a robust and performant solution through network isolation and extensive use of edge networks for DDoS protection, rate limiting, and low-latency DNS resolution (including custom domains). The converged architecture's intra-region High Availability (HA) and inter-region geo-failover characteristics help us meet the availability SLAs of Public Cloud deployments.

## Auth0 Services on Multi-Subscriber (Public Cloud) and Single-Subscriber (Private Cloud) Deployments

Auth0 is a Software-as-a-Service (SaaS) solution with two deployment models - Public Cloud and Private Cloud. The Public Cloud is a multi-subscriber environment where resources are shared between customers and is available in the United States, Europe, Australia, Japan, and now in the United Kingdom. Private Cloud deployments, on the other hand, are single-subscriber environments that provide customers with dedicated infrastructure and can be deployed in most regions across Amazon Web Services (AWS) and Microsoft Azure.

The Public Cloud offering is deployed on AWS and addresses the needs of a vast majority of customers. However, customers may choose Private Cloud for a variety of reasons, such as: 

* Geographical requirements that dictate deploying in an area not served by Public Cloud (e.g. for data residency and/or latency reduction)
* Industry-specific needs (e.g., PCI compliance)
* Preference for Microsoft Azure instead of AWS
* Higher transaction volume than allowed on Public Cloud

![Auth0 Services on Multi-Subscriber (Public Cloud)](https://images.ctfassets.net/23aumh6u8s0i/6ex2w8DgyfbKhdJLx1lIPi/60a5ba0c641c9059317da35e9f6aab1c/multi-subscriber-public-cloud-01.png)

## Why Converged Architecture?

The converged architecture allows us to deploy and manage both Public and Private Cloud offerings on the same underpinning. This architecture is built on the following premises:

* Multi-cloud: AWS and Azure cloud support through a common interface
* Container orchestrated: use of container images instead of installing packages
* Stateless: scalable and replaceable by design
* Immutable: run only trusted code and configuration
* Fully automated: provisioning, upgrades, and decommissioning are done by machines
* GitOps: enhanced DevOps, push code and safely reproduce it thousands of times

![Architecture](https://images.ctfassets.net/23aumh6u8s0i/57nIODdJEv5clLYYswHEl5/12fabdd26c7eddf4db40754196ef1659/multi-subscriber-public-cloud-02.png)

The benefits of a single underlying architecture for developing, deploying, and operating services across different environments are manifold. The primary reason is the ability to offer new capabilities to customers faster and at a lower expense. The architecture also allows us to ensure feature parity across different deployment environments seamlessly.

The converged architecture helps in focusing the organization’s energy on a common infrastructure that yields higher developer productivity/velocity. It results in improved platform scalability to address various scaling demands from both multi-subscriber and single-subscriber deployments. It provides a constructive space for assessment and adoption of security practices that might be perceived as unique to one deployment environment type, but have practical implications on the other as well. It also helps with reliability refinements and enhancements across the board. 

Besides optimizing engineering resources, a converged architecture has several other internal benefits through unified automation, toolsets, and processes. It has expedited identification and realization of infrastructure and operational cost optimizations across the board, which helps deliver good value to our customers.

## Deployment Characteristics of Multi-Subscriber Services 

As a reminder, the Public Cloud is designed to host thousands of subscribers over shared resources, whereas a Private Cloud deployment is designed for a single subscriber. 

Ensuring optimal performance and security for the different Public Cloud subscribers is paramount. While the underlying compute, storage, database, networking, domain name, and other resources are shared in a multi-subscriber deployment, this solution ensures each subscriber is isolated within this shared environment.

The database and application workloads are partitioned to ensure an appropriate level of data isolation and security. The Auth0 Public Cloud combines pooled partitioning (i.e., partitioning of data by subscriber identifier) and on-demand subscriber-specific workload instances. The architecture is refined continuously to eliminate “noisy neighbor” problems.

## Public Cloud Platform Infrastructure Architecture

### Tiers - Central, PoPs, and Spaces

Once again, the converged architecture has three tiers - Central, Points of Presence (PoPs), and Spaces. Besides these, the Edge network for DNS and DDoS protection, and Auth0 HQ based systems for analytics and operations complete the picture.

![Tiers - Central, PoPs, and Spaces](https://images.ctfassets.net/23aumh6u8s0i/5wVpjNsZNeyRnxGmRIHLwM/deee78839a615f2ebc1679b65eafc873/multi-subscriber-public-cloud-03.jpg)

It’s important to note that the solution has been designed with isolated fault domains; the control plane and data plane separation allows the central control plane to be offline/under maintenance without impacting customers’ authentication flows.

* **Central**: A globally unique component that contains the platform control plane and other centralized global infrastructure. The control plane manages the creation of Public Cloud environments and keeps them updated with continuous (daily) releases.
* **PoPs**: An intermediate point of infrastructure pinned to a specific cloud region (e.g., AWS us-east-1). The PoP hosts internal visibility tools and securely proxies messages from the central down to the regional Public Cloud environments.
* **Space**: The Public Cloud environment is located ‘beneath’ a PoP in a particular AWS region. These spaces have cross-region geo-failover capabilities to ensure resiliency.

### Aspects - control and runtime, scalability, datastores, networking, and reliability

When Auth0 took on the converged platform project, it started as a small team, initially focused on our single-subscriber (Private Cloud) offerings. This team comprised a cross-section of our platform teams with expertise ranging from Kubernetes to API, tooling, infrastructure, and datastores. They were focused on developing a proof of concept for the converged platform.

As we learned from our experiments — and as the converged platform evolved and matured — we launched single-subscriber environments for general availability. You may read more about this in a series of posts we shared outlining the technical, security, and architectural decisions we made:

* [A Technical Primer of Auth0’s New Private Cloud Platform](https://auth0.com/blog/a-technical-primer-of-auth0-s-new-private-cloud-platform/)
* [The Architect’s View of Auth0’s New Private Cloud Platform](https://auth0.com/blog/the-architect-s-view-of-auth0-s-new-private-cloud-platform/)
* [Securing Auth0's New Private Cloud Platform](https://auth0.com/blog/securing-auth0s-new-private-cloud-platform/)
* [Data Pipelines on Auth0’s New Private Cloud Platform](https://auth0.com/blog/data-pipelines-on-auth0-s-new-private-cloud-platform/)
* [How We Do Releases in Auth0’s New Private Platform](https://auth0.com/blog/how-we-do-releases-in-auth0-s-new-private-platform/)
* [Optimizing Cost and Performance of Auth0's Private Cloud](https://auth0.com/blog/optimizing-cost-and-performance-of-auth0s-private-cloud/)

We continued the logical progression with the converged platform, and adopted it for Public Cloud. Behind the scenes, the team continued to grow, and eventually, as we began to gain more and more traction from the converged platform, we organized the team into specialties to best support growth.

* **Runtime -** Heavily focused on our Terraform and Kubernetes layers. Ensuring that the core of the platform functions and that automation has the flexibility to meet the needs of product delivery teams.
* **Control -** Owners of our controlling API and platform CLI. The tooling that is used for operating the platform in all cases both normal and incidents.
* **Datastores -** Focused on our data storage technologies and interacting with our product delivery teams and the most efficient way to utilize the available stores.
* **Networking -** Owners of our edge technologies and supporting the myriad of ways in which our customers leverage the edge.
* **Sizing -** Partners with other internal teams to establish the performance characteristics of our offerings and additionally adds improvements to our platform including auto-scaling.
* **Services -** Owners of tooling and services leveraged by product delivery in their development. This includes abstractions that allow for easier access to the underlying platform.
* **Data -** Responsible for ensuring the data flow from the individual environments to the regional Points of Presence (PoPs) and beyond. This includes application logs for support as well as abstracted metrics. 

In order to get the technology behind a solution right, it's critical to fully enable the people behind the technology to co-create innovative solutions. At Okta, we cultivate a BLOC culture, which stands for “Builder, Learner, Owner, and Collaborator.” These values foster a high-functioning, well-oiled machinery that can take on big and small challenges effectively and efficiently.

![BLOC culture](https://images.ctfassets.net/23aumh6u8s0i/1uDGWPkHZzzH5CKHlrvEbJ/114d89fab2474e4cb2aec9272dea795f/multi-subscriber-public-cloud-04.png)

With the different team specializations, collaboration becomes all the more important. At Auth0, we value documentation not only for informing but also for decision-making. Our Engineering teams follow a simple mantra for collaboration: "Write. It. Down." We use Request For Comment (RFC) documents to record architectural designs and Decision Record documents to discuss and align ideas across teams. These documents also provide important context for new team members about what we're building and how we arrived at the decisions we've made and served as an important knowledge base as we began onboarding service owners to the new converged platform. These core tenets have become critical for sustaining the growth of the platform and introducing new capabilities over time.

### Reliability

The converged architecture provides a highly reliable and available solution leveraging not only the High Availability (HA) constructs across three Availability Zones within an AWS region, but also geo-failover capability between Active and Failover regions.

![Reliability](https://images.ctfassets.net/23aumh6u8s0i/2jbDdi3fCuZ1hm6D0qyWCI/ffe5decea1a0c72156636d38073d1975/multi-subscriber-public-cloud-05.png)

The geo-failover regions are always synchronized from the datastores’ perspective, with demanding RPO/RTO and 99.99% availability SLA targets. Once the failover decision is made, a fully automated process is initiated for the failover to take effect.

![Reliability](https://images.ctfassets.net/23aumh6u8s0i/5HQ6xBqVyquDFEK7ewW4kC/299cf5878d8cee63c706c633cc0b1abf/multi-subscriber-public-cloud-06.jpg)

In the event of a multi-region failure (an extremely rare event), we can perform an automated restore from the last backup.

The historical availability metrics are a testament to the robustness of the Auth0 solution. We continue to meet our targets in Private Cloud with the converged architecture and expect to continue meeting or exceeding these targets with Public Cloud deployments on this architecture.

![Private Cloud](https://images.ctfassets.net/23aumh6u8s0i/3xjskcZcaHUYxFuePah6r4/fdd40e7755462d852c29d16293a3bc2e/multi-subscriber-public-cloud-07.png)

## What Next?

Auth0’s Public Cloud offering continues to be boosted across different facets. The availability of Public Cloud across geographies will continue to expand. The launch of the UK Public Cloud region in April 2023 is the latest example, providing yet another regional point of presence for customers with data residency and latency sensitivity needs. Also, support for a Public Performance tier in H2 2023 caters to customers’ higher performance needs on Public Cloud.


We look forward to continuing to deliver new and enhanced customer identity capabilities, ease of use, platform resilience, scalability, and security in our Private Cloud and Public Cloud offerings through the new converged architecture.

Multi-Subscriber (Public Cloud) Deployment on Converged Architecture

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

Martin Gontovnikas, a.k.a Gonto, is a software engineer at heart who moved to the ‘dark side’ and became VP of Marketing at Auth0. He considers himself lucky to have found a way to combine his two passions and apply his engineering thinking model to marketing.<br/><br/> Gonto’s analytical thinking is a huge driver of his data-driven approach to marketing strategy and experimental design. He is based in the Bay area, and in his spare time, can be found eating gourmet food at the best new restaurants, visiting every local brewery he can find, or traveling the globe in search of new experiences.

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

Tips for a secure and organized data migration process. 1. Workflow and project management tools 2. User identity and access management 3. Clear customer communication



Data is the foundation of a company's success. It provides the basis for customer insights, corporate strategy, and operational efficiency. As more companies embark on [digital transformation](https://auth0.com/app-modernization), migrating this critical information — particularly sensitive customer data — to a new platform(s) can be a burden. Moving data can unearth inaccuracies, unknowns, and/or duplicate entries, making it insufficient to use and requiring significant changes. 

The tips below will help ensure that the movement of your most sensitive information is secure, organized, and accessible to your users.

<include src="TweetQuote" quoteText="Data is the foundation of a company's success. This post will help ensure that the movement of your most sensitive information is secure, organized, and accessible to your users!"/>

---

## Issues That Can Arise with Data Migration
Before we dig into strategies for success, it's important to understand the issues that can arise in data migration. The process can be thorny for several reasons.

### Lack of Consideration for the Process
Teams are generally focused on selecting and configuring their new system. Testing potential tools and comparing the models are generally more exciting and inspiring than the mechanics of lifting data out of the legacy package. If data is uploaded in its current state, any errors or irrelevant aspects could become amplified and increase the information's exposure to risk. Because of this, it's important to be sure your team is on the same page about the nuances of the process and has a specific roadmap marked with individual roles and responsibilities.

### Improperly Tracking Users
It's critical to manage user identities and monitor for suspicious activity when you're migrating sensitive information. Companies that rely on consumer data, in particular, must validate all entries against new regulations — [GDPR](https://auth0.com/docs/compliance/gdpr/features-aiding-compliance/protect-user-data), for example, along with more specialized industry standards such as Sarbanes-Oxley (SOX) for financial institutions and the Health Insurance Portability and Accountability Act (HIPAA) for many healthcare providers.

### Poor Communication of Updates
Making sure your end users understand how you are securing their data after you've updated your apps is important for maintaining their trust. If you can't articulate what you are doing with their information, it's unlikely they will stick around. Documenting your work and developing a clear communication strategy are essential to making sure your data migration supports your company's overall goals for growth.

To address these potential issues, the following strategies focus on workflow, user access, and communications.

<include src="ebook-ads/UserMigrationYourWay" />

## 1. Organize Your Workflow and Project Management
To clearly understand and outline the steps required for a successful data migration, take time to consider the following:

- What will cause the least disruption to the daily operations of your system? That is, when are the best times to work on and/or migrate data sets of highest sensitivity or usage?
- What aspects of your strategy can you tag to teammates in-house, and where might you need to bring in outside expertise?
- How will you document your process, ensuring that all information is accounted for?
- Will you enrich your files after they have been moved with further information (e.g., customer names and/or account numbers)?

While this list is not exhaustive and each strategy will be unique, depending on an organization's current systems and future goals, it should aid in understanding the depth of thought required for an efficient data migration.

It can be helpful to use a workflow tool to organize your team and define your process. [Airtable](https://airtable.com/product) has a proven track record for improving internal organization. When mapping out your data migration strategy, Airtable can help define your project scope, set deadlines, and assign individual responsibilities.

For any task that you're organizing, Airtable will help prioritize tasks and ensure that you adhere to your overall goals:

![Airtable](https://images.ctfassets.net/23aumh6u8s0i/38brOxQrTQvBu8Pa8BBQ17/df355af7ec95291c2abff6758ccb9694/1-airtable)

> [Source.](https://airtable.com/product)

Within the grid view, you can check to see which tasks have been completed and quickly note whom to reach out to in case of a question or concern. Airtable also has a [calendar view](https://airtable.com/product) to better visualize the timeline of your data migration, which can quickly become lengthy and arduous without clear monitoring. Both views can help break down the potentially opaque data migration process into a concrete series of steps.

Additional tools to consider for managing the task of data migration include:

- [Asana](https://asana.com/guide/examples/company/project-management): Highly customizable, popular tool for engineering teams
- [Trello](https://trello.com/): Visual workflow; bulletin-board format
- [Jira](https://www.atlassian.com/software/jira): Supports distributed collaboration

Taking time to think through your steps at a granular level and selecting a tool that will hold your team accountable will help you succeed.

## 2. Clearly Track Who Accesses Customer Data
Understanding who is accessing and updating portions of sensitive customer data at any given time during the data migration process is critical to maintaining integrity. In today's environment of [increasing industry regulations](https://auth0.com/gdpr) around consumer data, this core function must be up-to-date and as tight as possible. 

Because of the complexity and urgency of this task, many teams choose to outsource their [identity management](https://auth0.com/app-modernization) when migrating data, particularly as part of a larger [digital transformation](https://auth0.com/learn/identity-management-drives-digital-transformation/).

[Auth0's user management dashboard](https://auth0.com/b2e-identity-management-for-employees) allows a systems administrator to authorize new users, track their behaviors, and evaluate their performance according to the company's policies.

![Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/5IwuLEHPTS1w1q7UhTcUPk/277cb0224267a945a4265e0984263142/2-auth0-manage)

> [Source.](https://auth0.com/learn/cloud-identity-access-management/)

In the Auth0 dashboard, an administrator will have a clear view of users at any point. In addition, Auth0's identity platform offers enhanced options like multi-factor authentication, anomaly detection, and advanced logging. For example, if the administrator notices a certain user has a series of failed login attempts, they can [block access](https://auth0.com/docs/anomaly-detection) to investigate further. 

From a user perspective, this function is an invisible and painless part of their workflow. 

## 3. Explain Your Data Policy Changes
If you can clearly communicate your data migration and updated data usage policies to your users, you will gain their trust — and an edge over your competitors. At the moment, very few company blogs or statements spell out the details of data usage in a digestible format — as we've recently seen with Facebook's [confusing policies](https://www.wired.com/story/mark-zuckerberg-congress-day-one/). 

You have an enormous opportunity to distinguish yourself in the field if you can fill this information gap. A major data migration is a perfect opportunity for you to document previous work and latest updates. Making this information immediately visible, user-friendly, and clearly accessible is key:

![Facebook](https://images.ctfassets.net/23aumh6u8s0i/7mn6vdZtybE6e5Rlg1dSNa/10c9a53747ac05ec8598251b03153990/3-zuck)

> [Source.](https://www.recode.net/2018/3/28/17171496/facebook-settings-redesign-cambridge-analytica)

While hopefully your team will not be recovering from a data leak like [Facebook's](https://auth0.com/blog/cambridge-analytica-and-facebook/), the tech titan provides an excellent example of how to communicate a change in policy to users. Three key points to include when explaining your updates are:

1. Place a brief summary of the information on the front of the app where users will see it immediately without any digging.
2. Include a clear CTA or way in which users can click to read further details.
3. Make sure any actions your user must take to delete or update their data settings are very simple.

You must make your user feel as though they are well supported and in full control. Both sets of information — your summary and fine print — should feel friendly and encouraging. Employ your best writers and incorporate welcoming images or a set of bullet points to truly put your best foot forward.

## Don't Be Afraid to Change
[90%](https://auth0.com/learn/how-auth0-uses-identity-industry-standards/) of businesses today state that legacy software systems are keeping them from achieving their goals. Despite increasingly strict regulations, you should not be afraid to scale and innovate. Just be sure you take the process of data migration seriously as you search for your new platform. Make sure the right people access the correct pieces of data at the proper times during the migration and then seize the opportunity to demonstrate how bulletproof your new strategy is with excellent customer communications.

<include src="TweetQuote" quoteText="90% of businesses state that legacy software are keeping them from achieving their goals. Scale and innovate while paying attention to data migration to succeed!"/>


"efficiency"