Summary

  • The September 2020 Azure Active Directory authentication outage matters because identity was the common gate for Microsoft 365 and dependent cloud services, so recovery had to be judged by practical access restoration rather than by a single component's apparent health.
  • Public accounts described authentication errors across Microsoft services after a change affecting Azure Active Directory, followed by rollback and mitigation work. The public file is useful, but it does not expose every private deployment artifact, customer-specific impact, or control test.
  • The accountability question is who had practical control over deployment safety, rollback validation, authentication dependency mapping, administrator visibility, customer workaround guidance, recovery sequencing, and proof that dependent cloud services were actually usable again.
  • Customers also had a responsibility to understand how much of their work depended on one identity provider, which privileged actions would remain possible during an authentication incident, and whether manual or alternate access paths were real rather than theoretical.

Identity became the cloud control plane

Azure Active Directory, now part of Microsoft Entra ID, is not merely a login screen. It is a control plane for access to email, collaboration, office documents, administration, device management, SaaS applications, security tooling, workflow automation, and partner integrations. When that identity layer fails, the affected user may not see an "identity platform" problem. The user sees Outlook, Teams, SharePoint, Office.com, the Azure portal, line-of-business applications, or an integrated SaaS workflow that cannot be reached. The dependency is abstract to the user and concrete to the organization.

The September 2020 outage matters because it made that abstraction visible. Public status summaries and contemporaneous reporting described authentication problems affecting Microsoft 365 and related services after a Microsoft change involving Azure Active Directory. Microsoft then worked through rollback and mitigation steps. This article treats the public record carefully. It does not claim access to Microsoft's private deployment logs, code changes, customer tenant telemetry, or internal root-cause review.

It uses the public incident record, Microsoft status and service-health documentation, Microsoft identity and resilience documentation, and third-party reporting as evidence of what could be known outside Microsoft.

That evidence is enough to identify the accountability frame. Identity is upstream of many cloud services. A deployment or configuration problem in identity can appear downstream as a broad productivity outage. A rollback may not be accountable until users can actually sign in or renew sessions, administrators can see service health, dependent applications accept tokens, and customer support can tell users what to do. Provider-side recovery and customer-side recovery may not happen at exactly the same moment. That distinction is the heart of the control-plane problem.

Microsoft's current Azure status history entry point at https://status.azure.com/en-us/status/history/ and Microsoft 365 service-health guidance at https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health?view=o365-worldwide show the public and administrator-facing channels through which customers are supposed to classify service incidents. The Microsoft 365 Service Communications API overview at https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-service-communications-api-overview?view=o365-worldwide shows a more automated path for health and message-center data. These sources do not by themselves prove every September 2020 detail. They show that service-health evidence is part of the operating model for Microsoft cloud customers.

The identity surface is defined in current Microsoft documentation as well. Microsoft Entra ID fundamentals at https://learn.microsoft.com/en-us/entra/fundamentals/whatis describe the identity platform. Authentication documentation at https://learn.microsoft.com/en-us/entra/identity/authentication/overview-authentication and multifactor authentication documentation at https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mfa-howitworks describe customer-facing identity controls. Monitoring and health guidance at https://learn.microsoft.com/en-us/entra/identity/monitoring-health/overview-monitoring-health gives customers a vocabulary for observing identity state. These documents are current product context, not a retroactive incident postmortem. They are still necessary because they explain why an authentication outage is a control-plane event.

The first accountability lesson is therefore basic: an organization cannot inventory cloud risk only by application name. It has to inventory access paths. If email, meetings, file sharing, help desk, security alerts, device management, application launchers, business-process automation, and administrator consoles all depend on the same identity tenant, they are not independent continuity risks. They are one identity dependency cluster. That cluster can be disrupted even when storage, compute, and networks remain healthy.

A status record is not the same as access restoration

Status communication is essential in an identity outage because customers need to know whether failed sign-in is local misconfiguration, user error, tenant-specific policy, network failure, expired credentials, MFA friction, conditional-access behavior, or a provider-side incident. The September 2020 event forced that distinction at scale. If administrators could not reliably authenticate, the very people responsible for diagnosis and communication might have reduced visibility at the moment they needed it most.

A status page can say that a provider has identified a problem, rolled back a change, or is seeing signs of recovery. Those statements matter. They do not automatically prove that every customer workflow is restored. A user may have an active session and remain productive while a new sign-in fails. Another user may be locked out because token refresh fails. An administrator may see the status post but be unable to execute a tenant change. An application may accept some tokens but fail a specific integration path.

A security team may see alerting delays or failed automation because the identity dependency is upstream of the tool that would normally respond.

This is why recovery evidence has to be measured at the level of practical access. For a provider, recovery may mean authentication error rates return to baseline, a deployment is rolled back, or service telemetry stabilizes. For a customer, recovery may mean users can sign in, MFA flows complete, administrators can reach portals, dependent applications accept tokens, support tickets fall, and any queued work is cleared. Both measures can be true. They are not identical.

Microsoft's identity resilience material is relevant because it gives customers vocabulary for this distinction. The resilience overview at https://learn.microsoft.com/en-us/entra/architecture/resilience-overview and credential resilience guidance at https://learn.microsoft.com/en-us/entra/architecture/resilience-in-credentials discuss how identity systems should be designed for availability and recovery. Microsoft guidance on application and identity resilience at https://learn.microsoft.com/en-us/entra/architecture/resilience-with-microsoft-entra-id gives another entry point into continuity design. These sources do not assert what happened in September 2020. They show that identity resilience is a designed control, not a matter of hoping sign-in works.

Customer-side evidence should include sign-in logs, token-error patterns, affected user groups, affected applications, administrator actions that failed, break-glass account tests, support-contact timing, local status messages, and recovery confirmation. Provider-side status is not enough. A board that receives only "Microsoft restored service" does not know whether the organization cleared delayed approvals, rescheduled meetings, reconciled automated tasks, or reviewed privileged-access continuity.

The distinction is also important for public-sector continuity. Schools, universities, municipalities, public agencies, contractors, courts, health services, and civic programs may use Microsoft 365 and Microsoft identity services for everyday work. Many uses are not life-critical. Some are deadline-sensitive or public-facing. If sign-in fails during a service window, the organization needs more than a global status update. It needs a local decision: which functions pause, which can continue through existing sessions, which users need alternate contact, which records must be preserved, and which public notices are required.

Deployment safety has to include rollback proof

The manifest frame for this article emphasizes deployment rollback failure because the public record around the September 2020 outage was not only that authentication failed. It was that a change and subsequent mitigation did not immediately restore expected behavior for affected users. The accountability principle is broader than this single incident: a deployment is not safe merely because it can be rolled back in a technical sense. It is safe when rollback has been validated against the user and service behaviors the deployment can break.

Identity deployments need especially conservative safety rules because authentication sits upstream of many services. A change may affect token issuance, token validation, session renewal, conditional access, MFA, federation, device compliance, service-to-service authentication, or administrator access. A rollback plan has to test the same paths. If rollback restores one path but leaves another degraded, customers still experience an outage. If rollback requires administrators to perform tenant-side actions but administrators cannot authenticate, the workaround may be weak.

If monitoring focuses on component health but not dependent-service access, recovery can be declared too early.

Microsoft's broader reliability and architecture documentation helps frame the standard. Azure reliability guidance at https://learn.microsoft.com/en-us/azure/reliability/ and the Azure Well-Architected reliability pillar at https://learn.microsoft.com/en-us/azure/well-architected/reliability/ treat reliability as design, monitoring, failure response, and continuous improvement. Azure Architecture Center resilience material at https://learn.microsoft.com/en-us/azure/architecture/framework/resiliency/overview gives general language for resilience and failure-mode planning. Those are broad current references, not a specific September 2020 RCA. The relevant point is that deployment safety and rollback proof belong inside reliability, not outside it.

For an identity provider, rollback proof should include several layers. First, can new sign-ins complete across major customer segments? Second, can existing sessions renew or continue safely? Third, can administrators reach health, support, and policy interfaces? Fourth, can dependent services such as Microsoft 365 applications, Azure portal operations, and third-party integrated applications use identity normally? Fifth, can customers see enough status detail to avoid creating harmful workarounds? Sixth, can the provider prove the problem is mitigated without hiding residual customer-side recovery work?

The public record does not allow outsiders to judge every Microsoft internal control. It does allow customers to ask for better evidence discipline in their own environment. A customer can keep independent break-glass accounts, test privileged access outside normal conditional-access paths, document which applications depend on Microsoft identity, preserve sign-in telemetry, subscribe to service-health channels, and create a communication plan for users. These actions do not remove Microsoft responsibility for provider-side changes.

They prevent the customer's entire incident response from depending on the same identity plane that is impaired.

The deployment lesson is also relevant to enterprise software automation. Many organizations use Microsoft identity as the entry point for automated workflows: approvals, bots, scheduled jobs, SaaS connectors, device-compliance enforcement, data-loss prevention, and security response. A sign-in outage may not only stop a user from opening email. It may stop an automated business process from approving an invoice, routing a ticket, renewing a session, applying a policy, or contacting a downstream service. Rollback proof should therefore look at automation health as well as human sign-in.

Administrator visibility can fail with the same identity dependency

An identity outage can impair the very channels needed to manage the incident. Administrators may need to reach the Microsoft 365 admin center, Azure portal, Entra admin center, service-health pages, support channels, and tenant logs. If those paths depend on the impaired identity layer, administrator visibility becomes a continuity risk. A customer may see user complaints before it can see provider status. A support desk may have to respond with incomplete information. Security teams may hesitate to change policy because they cannot prove whether the failure is provider-side or tenant-side.

Microsoft's service-health guidance is therefore an accountability source. The service-health documentation at https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health?view=o365-worldwide explains how administrators view incidents and advisories. The Service Communications API at https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-service-communications-api-overview?view=o365-worldwide gives organizations a way to integrate service communications into their own systems. The value of the API is not merely convenience. If a customer's incident workflow can ingest provider health messages into a channel that does not rely on the affected portal path, it has more resilient visibility.

Customer visibility should also include local monitoring. Microsoft Entra monitoring-health material at https://learn.microsoft.com/en-us/entra/identity/monitoring-health/overview-monitoring-health and sign-in reporting concepts in Microsoft documentation help customers see identity events inside the tenant. But tenant logs are only useful if they remain accessible, retained, and understood. During a provider-wide incident, local logs may show symptoms before the provider status page is specific enough. After recovery, local logs help prove which users and applications were affected. Without local evidence, the organization may have only anecdotes and a public status message.

Break-glass access is a related control. Microsoft's emergency-access guidance at https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access recommends maintaining emergency access accounts for privileged operations. That guidance is not a finding about September 2020. It is relevant because identity incidents test whether emergency access is a documented, monitored, and rehearsed control. A break-glass account that no one has tested, that is blocked by the same conditional-access failure, or that is unavailable to the incident commander is not a reliable control.

Administrator visibility also has a communications dimension. Users do not need a detailed identity architecture diagram during an outage. They need to know whether to retry, wait, use an existing session, switch to phone, use an alternate tool, pause a workflow, or contact support. Administrators need enough provider and local evidence to give that instruction honestly. If the public provider status is vague and local telemetry is weak, customer communication becomes guesswork.

For public-sector and regulated organizations, that guesswork can create records-management and fairness problems. A school that cannot access learning tools may need to adjust deadlines. A public office that cannot reach email may need another published contact points. A regulated firm that cannot process approvals may need to document delay. A security team that cannot reach management portals may need to preserve a decision trail. Identity recovery is therefore also a recordkeeping problem.

Workarounds have to be real under impaired identity

Many continuity plans say that users can work around a cloud outage. In an identity outage, that claim needs testing. Existing sessions may remain usable for some users, but not for users who are signing in fresh, whose tokens expire, whose devices require reauthentication, or whose applications require a new token. Phone calls may substitute for meetings, but not for document access. Local copies may help, but not if access control, sharing, or current versions require cloud authentication. Alternate SaaS tools may exist, but not if they federate to the same identity provider.

A real workaround is specific. It says which users can continue using existing sessions, which functions must pause, which channels are independent, which administrators can reach support, which emergency accounts are available, which applications have local or alternate authentication, and what data can be used without violating policy. It also says when the organization will stop trying a workaround because it creates more risk than delay. For example, bypassing identity controls to keep a workflow moving may create audit or security exposure that is worse than a short outage.

Microsoft's trust and service relationship materials provide the contractual and assurance context for these questions. The Microsoft Trust Center at https://www.microsoft.com/en-us/trust-center gives a public entry point for security, privacy, compliance, and trust materials. The Microsoft Customer Agreement page at https://www.microsoft.com/licensing/docs/customeragreement gives relationship context for cloud services. These sources do not decide any 2020 incident remedy. They remind buyers that service dependency is governed through a mix of public status evidence, contract terms, assurance materials, customer architecture, and local continuity plans.

Customers should avoid two opposite errors. The first error is to assume Microsoft is responsible for every downstream business interruption once an identity incident occurs. Customers choose how deeply identity is embedded, how much redundancy they buy, how they communicate, and whether they test break-glass access. The second error is to treat identity outages as purely customer responsibility because customers should have designed around them. Microsoft controls the identity service, deployment safety, rollback mechanisms, public status language, and much of the evidence needed to understand provider-side failure.

Accountability requires both lanes.

This dual-lane structure is why status and local telemetry should be preserved together. A customer should be able to say: provider status reported an authentication incident at a given time; our sign-in logs show these user groups and applications failed; existing sessions behaved differently from new sessions; emergency access was or was not used; support sent these messages; business work was delayed in these ways; recovery was confirmed by these tests. That record is far stronger than a generic vendor-risk note.

The September 2020 event also shows why organizations should not centralize every support and incident function behind the same identity path without an alternate. If the support portal, documentation, incident bridge, emergency contact list, and executive reporting are all inaccessible because the identity plane is impaired, the organization has built a common-mode failure. The fix may be modest: exported contact lists, alternate conferencing, independent status hosting, service-health API ingestion, and rehearsed emergency accounts. The control has to be explicit.

Public reporting should preserve uncertainty

Contemporaneous public reporting is useful but has limits. Media reports described broad Microsoft 365 and Azure Active Directory authentication issues, including impact on services such as Outlook, Teams, Office.com, and administrative access. For example, BleepingComputer reported on Microsoft 365 authentication issues at https://www.bleepingcomputer.com/news/microsoft/microsoft-365-outage-causes-authentication-issues-globally/ and The Verge reported on Microsoft 365 service disruption at https://www.theverge.com/2020/9/28/21492361/microsoft-365-office-outage-down-outlook-teams. These reports are helpful evidence of public impact and public messaging. They are not substitutes for Microsoft internal logs or customer-specific telemetry.

The public uncertainty should remain visible. It is reasonable to say that the outage was associated with Azure Active Directory authentication and a Microsoft change-and-mitigation sequence because that is how the public event was reported. It is not reasonable to claim exact tenant-by-tenant effect, every internal deployment control failure, every business loss, or every successful workaround from public reporting alone. A mature accountability article should resist turning a public outage into a courtroom conclusion.

Preserving uncertainty does not weaken the lesson. It strengthens it. The lesson is not that outsiders know every Microsoft internal fact. The lesson is that customers can still identify the control class and improve their own evidence. Identity-provider availability is a systemic dependency. Deployment rollback must be judged by practical access restoration. Service health must be visible outside the impaired path. Break-glass access must be tested. Business workflows must know what to do when identity is degraded. These conclusions do not require private source code.

The same restraint applies to legal and contractual language. This article does not determine damages, service credits, negligence, regulatory breach, or contractual fault. It evaluates operational accountability: control, evidence, communication, fallback, recovery proof, and dependency mapping. That is the level at which boards, public agencies, schools, and enterprises can act without waiting for private litigation or confidential vendor review.

External frameworks can help keep the review disciplined. The NIST Cybersecurity Framework at https://www.nist.gov/cyberframework gives a public vocabulary for governance, identification, protection, detection, response, and recovery. NIST contingency planning guidance at https://csrc.nist.gov/pubs/sp/800/34/r1/final gives a lifecycle for contingency planning and testing. NIST SP 800-53 at https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final gives control families for access control, contingency planning, audit, incident response, and configuration management. These sources are not Microsoft incident findings. They give customers a way to convert a cloud identity outage into an auditable control review.

The review should also include enterprise software automation. If automated workflows use Microsoft identity for service accounts, delegated permissions, connectors, or administrative APIs, the outage can create a silent backlog. Human users may complain quickly. Automated jobs may fail quietly, retry, duplicate work, or wait for a token. A post-incident review should examine automation logs and not only user sign-in tickets. Identity is not only an employee access layer; it is a machine-to-machine workflow dependency.

Tenant evidence has to separate sign-in, session, and application failure

Identity incidents become confusing because users report the application they were trying to use, not the control plane that blocked them. A help desk may receive complaints that email is down, meetings cannot be joined, a document cannot be opened, a workflow approval failed, a device cannot enroll, or an application portal has stopped loading. Those complaints may share a sign-in cause. They may also include local device issues, tenant policy issues, network problems, expired passwords, MFA fatigue, or unrelated application defects. The customer evidence file has to separate these possibilities quickly.

The first split is new sign-in versus existing session. Some users may continue working because they authenticated before the incident. Others may fail because they are starting a new session, moving to a new device, or refreshing a token. If the organization treats those experiences as inconsistent anecdotes, it will struggle to communicate. If it records session state, token refresh behavior, user group, application, and error category, it can explain why some users are affected and others are not. That explanation reduces unnecessary password resets, risky policy changes, and duplicate support work.

The second split is user authentication versus application dependency. A user may be able to sign in but still fail to access a dependent application because the application relies on another identity claim, group membership, API permission, conditional-access result, or service-to-service token. In enterprise automation, the affected actor may not be a person at all. It may be a connector, service principal, scheduled job, security tool, device-management process, or approval workflow. The post-incident file should therefore include application logs and automation failures, not only user tickets.

The third split is administrator visibility versus administrator authority. An administrator might see that there is a Microsoft incident but be unable to execute the privileged action needed to change routing, send tenant messages, inspect sign-in logs, or open a support case. Another administrator might have emergency access but hesitate to use it because the organization has not defined who authorizes break-glass activation. A tested emergency-access control should answer both questions: can the account work, and who is allowed to use it under which conditions?

The fourth split is provider recovery versus local recovery. Microsoft may report mitigation when platform telemetry improves. The customer still has to check whether users can authenticate, critical applications accept tokens, automated jobs have cleared, support tickets are declining, and delayed business work has been reconciled. Local recovery tests should be named in advance. For example, the organization might test a new user sign-in, an MFA flow, an administrator portal login, a critical SaaS application, a service principal job, a device-management action, and a support-channel message. Without named tests, recovery becomes a feeling.

These splits make the review more fair to both sides. They prevent customers from blaming Microsoft for local policy defects. They also prevent provider status from being used as a substitute for local impact evidence. The purpose is not to assign fault as quickly as possible. The purpose is to build a record that lets decision makers know what happened, what remained uncertain, what work was delayed, and which controls should change.

Procurement should price identity concentration explicitly

Identity concentration is often purchased indirectly. An organization buys productivity software, collaboration, device management, security tooling, workflow automation, and SaaS integrations. Over time, the identity provider becomes the shared gate for all of them. The buyer may never make a single explicit decision that says "we accept one identity control plane for this much of the business." The September 2020 outage shows why that implicit decision should become explicit.

Procurement and architecture reviews should identify which functions depend on Microsoft identity before a renewal, expansion, or major integration. The review should list human access, privileged access, application access, service accounts, external partners, schools or public users, automation jobs, security alerts, and recovery channels. It should also classify which functions can tolerate delay, which can continue through existing sessions, which require emergency access, and which must stop rather than bypass identity controls. That classification turns identity from a background assumption into a priced operational dependency.

Pricing identity concentration does not mean abandoning Microsoft identity or duplicating every system. A second identity provider can add complexity, inconsistent policy, weak governance, and new attack paths if it is not designed carefully. The point is to match continuity controls to risk. A low-criticality collaboration workflow may accept provider outage risk. A security operations workflow, public-service channel, payment approval, or regulated record system may need stronger evidence: emergency access, independent status communication, alternate contact paths, documented manual process, and rehearsed restoration checks.

The review should also ask which communications channels remain outside the affected path. If the organization's incident bridge, executive messaging, user notification drafts, support knowledge base, and administrator contact list all require the same identity provider, the organization may lose coordination during the outage. A small independent communications kit can be enough: offline contact lists, pre-approved public notices, alternate meeting instructions, a status page hosted through a separate dependency, and a clear rule for who sends updates. The control is inexpensive compared with the confusion it avoids.

Contract and assurance review should be equally precise. A service agreement or trust portal can frame obligations, but it cannot prove that a particular tenant's workflows are resilient. Procurement should ask how service-health notices are received, how historical incidents are preserved, how support escalation works during identity failures, how emergency access is documented, and how the customer will gather local evidence if provider identity is impaired. These questions do not require private Microsoft internals. They require the buyer to understand its own dependency.

The final procurement question is residual risk acceptance. If the organization decides that a major identity outage would pause some work, that may be acceptable. The decision should name the affected work, the expected tolerance, the user communication plan, and the owner. Silent risk acceptance is different. Silent acceptance leaves users, administrators, and boards to discover the dependency during the outage. The September 2020 Azure AD incident remains valuable because it turns that silent dependency into a concrete governance item.

That governance item should be revisited after every major identity or productivity-suite change. New SaaS integrations, device policies, conditional-access rules, automation connectors, mergers, school terms, public-service deadlines, and security programs can all expand the blast radius without a formal architecture project. A dependency map that was accurate last quarter can become stale quickly.

The accountable practice is a lightweight recurring review: which new workflows now depend on Microsoft identity, which emergency paths still work, which owners have changed, which logs are retained, and which recovery tests need to be repeated before the next outage turns a hidden identity assumption into a business interruption.

The recovery package should also include a tenant-level closeout that is separate from the provider's service-health closeout. That closeout should list the critical applications tested, the administrator paths tested, the automation jobs checked, the delayed approvals or messages reconciled, the users still reporting sign-in trouble, and the emergency-access accounts returned to normal custody. A provider may correctly report mitigation while one tenant still has stale tokens, failed connectors, or backlogged workflows. Conversely, a tenant may have a local configuration fault that continues after provider recovery.

Separating those states prevents both unfair blame and premature closure.

For regulated and public-service organizations, the closeout should be auditable. It should say who declared local recovery, what evidence they reviewed, what user groups remained affected, what communications were sent, and whether any manual workaround created a follow-up risk. Identity outages can create shadow processes: shared inboxes, temporary approvals, phone-based authorizations, paper records, or emergency accounts. Those processes may be necessary, but they have to be reconciled. Otherwise the outage ends technically while governance debt remains.

The most useful closeout also records what the organization chose not to change. It may decide that a single Microsoft identity dependency remains acceptable for most collaboration workflows, while emergency access and independent communications are enough for critical functions. That can be a defensible decision if it is explicit, dated, and tied to evidence from the outage. It is not defensible if the same hidden dependency reappears in the next incident without an owner, test, rehearsal, or accepted-risk record.

Reader evidence file

This article uses the following public sources as the evidence file for the Azure Active Directory September 2020 authentication outage, Microsoft 365 dependency, status communication, identity resilience, administrator visibility, customer fallback design, and enterprise/public-sector continuity. Microsoft-authored sources are treated as provider documentation and service-health context. Media sources are treated as public reporting about the incident, not as complete forensic evidence.

Board review questions

A board or risk committee should not ask only whether Microsoft had an Azure Active Directory outage in September 2020. It should ask which business processes depend on Microsoft identity, which applications and automated workflows fail when sign-in fails, which administrator paths remain available, which users can work through existing sessions, which service-health channels are monitored outside the affected path, and which local tests prove recovery.

The board should require evidence separation. Provider status can prove what Microsoft publicly reported. Tenant sign-in logs can prove local impact. Service-health API records can prove what the organization received. Break-glass tests can prove administrator continuity. Support records can prove user communication. Workflow logs can prove whether automation recovered. Contract and trust materials can frame obligations. None of those records should be forced to do the work of the others.

For this specific case, the governing question remains: who had practical control over deployment safety, rollback validation, authentication dependency mapping, administrator visibility, customer workaround guidance, recovery sequencing, and proof that identity restoration reached dependent cloud services? A complete answer should name Microsoft controls, customer controls, evidence gaps, affected audiences, and the repair evidence that would change a future identity architecture or procurement decision.