Best Buy Scales Google Cloud AI, but Shared Credentials Had to Go

Best Buy has replaced a credential-heavy access model as it prepares tens of thousands of users for a larger Google Cloud AI and analytics footprint. Until now, some access depended on service accounts, synchronized identities, and manually rotated keys. That structure became harder to defend as usage expanded.

The retailer now connects Microsoft Entra ID directly to Google Cloud through Workforce Identity Federation. The system validates a developer’s existing corporate identity when access occurs. It does not require Google to maintain a synchronized copy of every workforce record.

The change sounds like an identity modernization project. Its larger significance concerns whether Best Buy can expand cloud-based AI without multiplying credentials, administrative work, and ambiguous audit records. The old route treated access as something teams provisioned and maintained. The new route treats identity as a live trust relationship.

That distinction puts the established service-account model under pressure. It also illustrates a wider contest between synchronized cloud directories and direct identity federation. Best Buy is betting that its Microsoft identity system can remain the control point while employees use another provider’s data and AI services.

Best Buy Removed the Credential Layer Blocking Expansion

Best Buy’s immediate change was simple but consequential: developers now enter Google Cloud as identifiable employees instead of hiding behind shared service account credentials.

Best Buy described the project in a July 28 announcement. The retailer said its expanding analytics and AI activity created two related problems. It needed to reduce credential risk while avoiding the administrative friction of synchronizing thousands of backend users.

The company historically operated synchronization pipelines that copied backend identities from Microsoft Entra ID into Google Cloud. Entra ID is Best Buy’s existing corporate identity provider, which authenticates employees and applies enterprise access policies.

Best Buy used Cloud Identity without a Google Workspace deployment. That configuration left the technology organization needing a practical bridge between its Microsoft-managed workforce and its growing collection of cloud resources.

Power BI access to BigQuery exposed the limits of the earlier arrangement. BigQuery is Google’s managed data platform for analytics and AI workloads. Users working through Power BI previously relied on service account credentials when connecting to it.

A service account represents an application or process rather than a named employee. It can be appropriate for software workloads, but it weakens accountability when several people use its key for interactive access.

Each long-lived key also becomes an object that someone must issue, store, track, rotate, and eventually revoke. Best Buy said its security and platform teams had to know which credentials each team possessed. They also had to account for the possibility that a key might appear in a chat message or another uncontrolled location.

These are not isolated administrative annoyances. Every additional credential creates another path that must remain protected throughout its lifecycle. Growth increases both the number of paths and the consequences of losing track of one.

Best Buy’s new architecture removes that intermediate key from the employee access flow. A developer signs in with an existing Entra ID identity. Workforce Identity Federation then brokers trust between Microsoft’s identity system and Google’s resource controls.

The developer can reach BigQuery through Power BI or use direct API calls. Google Cloud records the activity under the individual identity rather than a shared service account. That gives security teams a clearer answer when an audit asks who accessed a dataset or changed a resource.

Best Buy says the design can support tens of thousands of users. It is now extending the model to a broader workforce as cloud services become more important to retail operations.

The expansion claim still needs measured results. Best Buy has not published adoption rates, migration duration, incident reductions, or administrative savings. However, the architectural change removes one obvious constraint before those users arrive.

For technology leaders, that sequence matters. Best Buy did not wait for identity administration to become an even larger bottleneck. It changed the access model before adding another large wave of users and workloads.

Why Google Cloud AI Made Identity Debt Harder to Ignore

AI expansion did not create Best Buy’s identity debt, but it made that debt much more expensive to carry.

Advanced analytics depends on broad access to data, development environments, models, and supporting APIs. AI projects add more teams, experiments, and automation to that landscape. A credential process that works for a small data group can fail when participation reaches enterprise scale.

The pressure falls first on Best Buy’s security and platform teams. They must let developers work quickly without losing control of sensitive retail data. They must also preserve evidence showing which person performed each action.

Shared service accounts create tension between those requirements. They can simplify an initial connection because a team receives one technical identity. Yet the same shortcut reduces individual attribution and introduces a long-lived secret that must remain protected.

Rotation does not eliminate that problem. It moves the problem into a recurring operational process. Teams must distribute replacement keys, update dependent tools, remove old copies, and confirm that production workflows still function.

An expired credential can interrupt work. A leaked credential can expose resources. A forgotten credential can remain available after the original business need disappears.

Google advises organizations to choose a more secure alternative whenever possible because service account keys require careful protection. Its workload identity guidance treats federation as the preferred model for external software workloads.

Best Buy’s use case concerns workforce identities rather than machine workloads, but the security principle is similar. Long-lived secrets shift responsibility toward storage and rotation. Federated access depends on short-lived tokens and an explicit trust relationship.

That shift becomes more important as data access spreads beyond a central cloud team. Analysts can query BigQuery through familiar business intelligence tools. Developers can access APIs directly. Future AI applications can bring additional operational teams into the same environment.

The identity layer therefore becomes part of AI capacity planning. More compute and better models accomplish little if every new user requires a parallel record, a manually managed credential, and another exception in an audit process.

Best Buy’s decision also preserves its Microsoft-centered workforce experience. Employees continue authenticating with familiar corporate credentials. The retailer does not need to make a second identity store the daily source of truth for those users.

This is where Google Cloud faces its own pressure. Enterprise customers frequently operate mixed technology environments. A retailer might use Microsoft for workforce identity and business intelligence while choosing Google for data processing or AI.

Cloud providers cannot assume that winning an AI workload also means replacing the customer’s identity provider. They need to accept external identities without weakening their own authorization and auditing systems.

Google positions workforce federation as that bridge. It supports SAML and OpenID Connect, two standards for exchanging identity information between providers. It can also map external attributes into resource access policies.

The result is more than single sign-on. Single sign-on makes the login experience familiar. Federation must also translate a trusted identity into permissions that Google Cloud can evaluate for a specific resource.

For Best Buy, the practical test is whether this model keeps pace with AI adoption. Every new dataset, project, and application introduces another authorization decision. Federation removes duplicate credentials, but it does not remove the need to make those decisions carefully.

Google Cloud Federation Replaces Synchronization With Live Trust

The central mechanism is stateless validation: Google checks an Entra ID token when access occurs instead of maintaining a duplicate workforce directory.

Workforce Identity Federation creates a trust relationship between a Google Cloud organization and an external identity provider. Entra ID authenticates the employee. Google then evaluates the resulting token and maps its claims to an identity that its access policies recognize.

A token is a signed digital statement containing identity information and a limited validity period. Google validates that statement at the moment of access. Best Buy no longer needs a synchronized Google-side user record for every federated employee.

This is the key reversal in the project. The old system copied identities into another environment and later tried to keep those copies current. The new system asks the authoritative provider for evidence whenever a person requests access.

Synchronization introduces several timing problems. A new employee might wait for a provisioning cycle before receiving access. A role change might not appear immediately. A departed employee’s copied record might persist until another system removes it.

Direct federation reduces those specific gaps because Entra ID remains responsible for authentication and the user lifecycle. If Best Buy revokes an employee’s access there, the company does not need to locate and rotate a separate personal key in Google Cloud.

Google still governs authorization inside its platform. Authentication answers who the person is. Authorization determines what that person can do after Google accepts the identity.

Best Buy can map Entra ID attributes and groups into Google Cloud access rules. That approach supports policies based on enterprise context rather than issuing a separate credential for each connection.

The company also gains more useful audit records. Instead of seeing an action attributed to a shared service identity, administrators can associate it with the employee who initiated it. That distinction helps with investigations, access reviews, and compliance reporting.

Stateless does not mean configuration-free. Best Buy had to establish identity pools, providers, attribute mappings, and access policies. A workforce identity pool groups external identities so administrators can control their access to cloud resources.

The retailer also made two implementation choices that reveal the project’s operational complexity. It separated provisioning and single sign-on into distinct Entra ID enterprise applications. This prevents changes in one function from unexpectedly affecting the other.

Best Buy also placed the Entra ID provisioning service account in a separate organizational unit and disabled single sign-on for that unit. Without that exception, enforcing single sign-on globally could block the account needed to configure provisioning.

That bootstrapping issue is easy to overlook. An identity policy can prevent the very automation required to establish the policy’s supporting environment. Best Buy avoided that loop by isolating the automation identity.

Developers see much less of this machinery. They authenticate once with their Microsoft credentials, then use Power BI or direct APIs. The value of the system comes partly from hiding the additional cloud boundary from their daily workflow.

That invisibility should not be mistaken for reduced control. Google’s access layer still decides whether the federated principal can use BigQuery or another supported service. Cloud audit logs can record the person’s activity under that principal.

The design also separates user access from software identity. Human developers should enter as themselves whenever practical. Applications and automated workloads still require their own identities, permissions, and lifecycle controls.

This distinction will matter as Best Buy deploys more AI systems. An employee querying data through Power BI is not the same actor as an autonomous process calling an API. Both need accountable identities, but their access patterns and safeguards differ.

Federating the workforce solves one part of that governance problem. It gives the retailer a cleaner foundation for assigning human responsibility before automated access grows further.

The Real Contest Is Federation Versus Copied Directories

Best Buy chose direct federation over duplicated identity records, but the broader cloud market still supports both patterns.

Directory synchronization copies users and groups from an authoritative system into a destination directory. It gives the destination a local representation of each identity. Many enterprise platforms use this pattern because local records simplify assignments and application integration.

The weakness appears at scale and during change. Copies must remain aligned with their source. Provisioning delays, failed updates, altered attributes, and stale accounts create work that has little connection to the business value of an AI application.

Best Buy had already experienced that administrative friction. The company’s technology teams maintained pipelines to move backend identities from Entra ID into Google Cloud. Its new model avoids maintaining those records in Cloud Identity for federated users.

Direct federation shifts the dependency. Instead of depending on a synchronization pipeline, access depends on Entra ID, token exchange, provider configuration, and Google’s validation path.

That is not the elimination of complexity. It is a decision about where complexity belongs. Best Buy prefers a live trust boundary over thousands of duplicated identities and employee-facing service account keys.

Other cloud providers make related tradeoffs. AWS recommends federation for human access, but its IAM Identity Center documentation says external users and groups generally must be provisioned before administrators make assignments.

AWS can connect to Microsoft Entra ID through SAML, while System for Cross-Domain Identity Management handles provisioning. Its external identity model lets employees use corporate credentials, but it retains synchronized user and group awareness inside IAM Identity Center.

That creates a useful contrast with Best Buy’s Google implementation. Both approaches avoid giving every employee a permanent cloud-native password. However, they differ in how much identity state the cloud platform maintains.

Microsoft applies the same secret-reduction principle to machine identities. Its federated credential guidance recommends federation or certificates over client secrets for external workloads.

These examples show that the industry direction is consistent even when implementations differ. Cloud providers increasingly encourage temporary, federated credentials. They still make different choices about provisioning, local directories, attribute mapping, and service coverage.

For enterprise buyers, the relevant comparison is not which provider offers a federation feature. All major providers offer several forms of it. The important questions concern how identity state moves, where policy lives, and what happens when a dependency fails.

A synchronized directory can preserve local user information during some external disruptions. It can also leave stale information behind. A stateless federated design avoids those copies but depends more directly on the source provider during authentication.

Neither architecture removes the need for emergency access. Administrators still need a tightly controlled path for incidents involving an unavailable identity provider, damaged federation configuration, or mistaken policy changes.

The Best Buy case is therefore less about Google defeating Microsoft. Microsoft remains the authority authenticating the retailer’s workforce. Google becomes more usable because it accepts that authority without demanding another user store.

This arrangement reflects how large organizations actually buy technology. They assemble cloud, identity, analytics, and productivity services from several vendors. An access design that demands one provider own every layer introduces migration work and resistance.

Google gains when Microsoft-managed employees can reach BigQuery without adopting another daily identity. Microsoft retains its place in the employee lifecycle. Best Buy reduces the number of credentials its teams must govern.

The service account loses its inappropriate role as a substitute for named human access. That is the primary opponent in this story, not another cloud vendor.

For developers, this boundary also improves operational documentation. When an incident record identifies the person, project, and affected resource, teams can build a more useful technical knowledge base. Shared identities make that history harder to interpret.

Fewer Keys Do Not Mean Automatic Security

Federation removes a credential-management hazard, but its trust configuration becomes a high-value control plane that Best Buy must continuously test.

Google and Best Buy describe the new model as reducing the attack surface associated with keys. That claim is reasonable at the architectural level. A credential that no longer exists cannot be copied from a laptop, pasted into chat, or forgotten in a repository.

However, the public case study does not establish a measured reduction in security incidents. It provides no before-and-after count of exposed keys, unauthorized requests, failed audits, or recovery time.

The article also does not disclose the number of users already migrated. It says the architecture targets tens of thousands and that Best Buy is scaling access to a broader workforce. Those statements describe capacity and direction, not completed adoption.

Federation concentrates attention on token validation and policy mapping. If administrators trust an overly broad claim, misconfigure an audience, or map a group incorrectly, a valid employee could receive more access than intended.

Attribute-based access can reduce administrative work because policies follow workforce characteristics. It can also distribute risk into the quality of those attributes. A mistaken group membership in Entra ID can become an authorization error in Google Cloud.

Security teams must therefore test both sides of the relationship. They need assurance that Entra ID issues the expected claims. They also need assurance that Google interprets those claims exactly as intended.

Least privilege remains essential. This principle gives each identity only the permissions required for its work. Federation does not determine the correct permission level by itself.

Best Buy must also separate employees from automated workloads. The company removed service account keys from the described developer access flow. It did not claim that service accounts disappeared from every application or backend process.

AI systems complicate that boundary. A developer can initiate an experiment, while scheduled pipelines and agents continue working without that person’s active session. Those processes need machine identities with narrow permissions and traceable ownership.

Google’s documentation lists the products that support federated identities and notes service-specific limitations. Best Buy must confirm compatibility before expanding the design across every cloud service involved in its retail operations.

Availability presents another tradeoff. A federated login depends on several functioning components, including Entra ID, network connectivity, Google’s token exchange, and correct provider configuration.

A disruption in that chain can prevent new sessions. Organizations need carefully limited emergency accounts or another recovery mechanism. Those exceptions require unusually strict monitoring because they sit outside the normal identity path.

Session behavior also deserves scrutiny. Revoking a person in the source directory should block future authentication, but existing tokens or sessions can remain usable until their configured lifetime ends. Shorter sessions reduce exposure but require more frequent renewal.

Auditability improves when actions carry named identities. Yet logs only help if teams retain, monitor, and investigate them. Best Buy still needs alerting that distinguishes normal analytical activity from unusual exports, permission changes, or access patterns.

There is also a governance question about AI data access. Identity can prove which employee reached a dataset. It cannot decide whether the dataset was appropriate for a particular model, prompt, or experiment.

Data classification, model governance, and privacy controls remain separate responsibilities. Federation makes enforcement more attributable, but it does not create the underlying rules.

The case study comes from Google Cloud and a Best Buy cloud engineering leader. It should be read as an official customer account, not an independent security assessment.

The strongest conclusion is therefore narrower than the marketing message. Best Buy removed long-lived shared credentials from one important access pattern. That gives its security organization fewer secrets to manage and clearer user attribution.

Whether the result remains controlled at full scale will depend on access reviews, policy quality, service coverage, and incident performance. Those outcomes have not yet been published.

Three Signals Will Show Whether the Model Scales

The next test is operational evidence: broader adoption must preserve individual accountability without rebuilding the administrative burden elsewhere.

The first signal is the percentage of Best Buy’s intended workforce using federation for active cloud access. The company says it is extending the architecture, but it has not provided a migration timetable or completion metric.

A broad rollout with limited exceptions would strengthen the case for stateless workforce identity at retail scale. A growing collection of service-account exceptions would suggest that tool compatibility or workflow design remains a constraint.

The useful metric is not simply the number of enrolled users. Best Buy should examine how many interactive connections still depend on long-lived credentials. It should also track how quickly new employees, transfers, and departures receive the correct access.

The second signal is the quality of authorization and audit outcomes. Named access should reduce ambiguous log entries and accelerate investigations. Best Buy has not released evidence showing whether those improvements have materialized.

Security teams should watch for incorrect attribute mappings, unexpected permissions, failed token exchanges, and access surviving employment changes. A decline in manual key-rotation work would confirm that federation removed operational debt rather than moving it.

An increase in authorization errors would weaken the rollout’s central promise. That outcome might indicate that identity synchronization was replaced by equally difficult policy maintenance.

The third signal is how the retailer handles nonhuman AI access. Workforce federation addresses employees and other human users. AI agents, pipelines, notebooks, and scheduled jobs still need distinct machine identities.

A mature expansion would keep those machine identities separate from employees while linking each one to an owner, purpose, and permission scope. It would avoid returning to downloadable keys simply because automated systems need unattended access.

That is where Best Buy’s project can influence other enterprises. The important precedent is not that employees receive single sign-on. Enterprises have offered that experience for years.

The precedent is that a company can preserve its existing Microsoft identity authority while expanding analytics and AI on Google’s platform. It can do so without placing another long-lived credential between the employee and the cloud resource.

If the rollout succeeds, identity federation becomes an enabling layer for multicloud AI adoption. Technology leaders can choose data and model services without creating another workforce directory for every platform.

If it struggles, the likely problems will appear in exceptions, policy mappings, service limitations, and recovery procedures. Those details determine whether the architecture works beyond a carefully selected BigQuery use case.

For developers, the immediate outcome is easier to see. They keep their established corporate login, while audit records can identify their actions. They no longer need to treat a shared key as the price of reaching cloud data.

For security teams, the work changes rather than disappears. They manage trust relationships, access attributes, session rules, emergency paths, and machine identities. Those controls are more centralized, but mistakes can affect a wider population.

For enterprise buyers, Best Buy’s decision offers a practical evaluation question: does a cloud platform accept the identities already governing your workforce, or require another store and lifecycle process?

Best Buy has selected the first path for its Google Cloud expansion. The architecture removes a known barrier before analytics and AI usage reaches a larger workforce. The next few months should reveal whether adoption, audit quality, and machine identity controls support that confidence.

Organizations considering the same shift should start with their own access evidence. Identify where humans still use service account keys, determine which cloud services accept federated identities, and measure how quickly revocation reaches active sessions. Google Cloud federation becomes valuable when those results improve, not merely when the login screen changes.