When Nvidia said Thursday that it plans to pay $13 billion to acquire Hugging Face, the question arose of whether the open AI platform would remain open when it becomes a unit of Nvidia. And the current lack of a single viable open alternative that does everything Hugging Face does for enterprises adds further complications for CIOs.

Rumors of the pending deal have been circulating for at least a week. 

In its announcement, Nvidia said, “Hugging Face will remain an open platform for the entire AI ecosystem. Developers will choose the models they want, the frameworks they want, the clouds and inference service providers they want and the computing platforms they want. Nvidia compute will not be required to build on or deploy through Hugging Face.”

It added that Hugging Face will continue to support open source and open weight models from every model builder, and “continue to support multi-cloud and multi-accelerator development and deployment, so builders can use the hardware and infrastructure that best fit their work.”

Hugging Face CEO Clément Delangue took to his X account to also reassure customers, noting, “open-source AI is at an inflection point” and pointing out that, for the business to scale, it needs “more compute, more support, more collaboration and more visibility. That’s why we went to talk to [Nvidia CEO] Jensen [Huang], who offered to do exactly that with us.”

Preserving the Hugging Face team

Nvidia is also attempting to retain some of the Hugging Face workforce. As part of the deal, according to Nvidia’s 8-K filing, the purchase price is $11.9 billion, with “approximately $1 billion” earmarked for “an equity-based retention program” for Hugging Face employees who agree to join Nvidia. It has yet to be announced how many members of the Hugging Face workforce, estimated to be almost 750, will be offered roles at Nvidia.

But despite the reassurances from Nvidia about maintaining the open nature of Hugging Face, analysts and consultants suggested that the truth may not be known until months, or even a year, after the acquisition finalizes sometime next year; the transaction is expected to close “in the first half of 2027.”

Cause for optimism

Enterprise CIOs can only wait and see what Nvidia will ultimately do. 

But in the meantime, there is cause for optimism, given the history of recent open source acquisitions, said Jason Andersen, principal analyst at Moor Insights & Strategy. 

“There is always a ‘sky is falling’ narrative” with these transactions, Andersen said, but in recent years, open source acquisitions have often turned out quite well.

“What happened to Red Hat after IBM bought it? Things got better,” Andersen said. “The same can be said for GitHub after Microsoft bought it. Or Google’s acquisition of Gemma. There are just too many examples of it going the right way.”

Justin Greis, CEO of consulting firm Acceligence, also sees this acquisition as potentially good news for enterprise CIOs. 

“If Nvidia turned [Hugging Face] into a walled garden or an obvious funnel toward Nvidia hardware, it could undermine the community and network effects it just paid nearly $13 billion to acquire,” he pointed out. “Nvidia is being unusually explicit that Hugging Face will remain model-, framework-, cloud- and accelerator-agnostic, including saying that Nvidia compute will not be required.” 

And, he added, Nvidia could indeed make Hugging Face even more enterprise friendly. 

“Nvidia itself points to the opportunity to improve Hugging Face’s reliability, safety, model evaluation, inference, and deployment capabilities. That is potentially a very big deal,” Greis said, noting that enterprises don’t simply need access to more models, they need confidence that those models can operate within complex environments with governance, security, performance, resilience, and lifecycle management around them.

Those needs make the combination compelling, he said: “Nvidia has the engineering depth, infrastructure expertise and ecosystem reach to significantly raise that bar. Hugging Face has been enormously successful as a developer and open-model platform. Nvidia now has the opportunity to help make it much more enterprise-grade: a place where companies can discover models, datasets, and AI components, but also increasingly evaluate, test, secure, operationalize, and deploy them with the level of confidence and rigor expected inside a large enterprise.”

Avoid a single dependency

Still, said Shashi Bellamkonda, a principal research director at Info-Tech Research Group, there are various practical steps that CIOs can and should soon take to preserve what they have already created within Hugging Face.

“This should be a clarion call for CIOs to treat Hugging Face and open source models as part of their enterprise supply chain, and if a production system depends on an artifact hosted on Hugging Face, keep a verified copy in a second registry, whether that is GitLab, Amazon S3, or an internal artifact store,” he said. “Enterprises should also consider the source for open models and develop a fallback plan such as the model developer’s own repository or another hub, because Hugging Face is the dominant platform today, but no enterprise should depend on one company’s availability, governance, or roadmap.”

Bellamkonda also pointed out that, by owning Hugging Face, Nvidia would gain valuable visibility into which models are gaining traction, how developers are deploying them, and which hardware ecosystems they run on. It would then “hold a powerful position in the distribution of new open models, so that combination of infrastructure ownership, market intelligence, and hardware influence should factor into CIO planning,” he said.

Mike Wilkes, enterprise CISO at Aikido Security, added that one of the factors that makes a CIO’s 2027 contingency planning in the face of Hugging Face’s new ownership difficult is that there are not that many large open source companies that could directly replace Hugging Face for an enterprise.

“No true replacement exists for Hugging Face at its scale, but there are ways to avoid making it a single point of dependency,” he said. “Azure AI Foundry is probably the closest enterprise alternative regarding model breadth, now advertising more than 11,000 models and supporting models from OpenAI, Anthropic, Meta, Mistral and others. AWS SageMaker JumpStart is another option, as enterprises can create private curated model hubs with their own governance controls. Google’s Model Garden is a third viable choice and supports both managed and self-deployed open models inside the customer’s own cloud environment.”

But adopting any of those alternatives means a move from an independent Hugging Face to Microsoft, Amazon, or Google, “so they change the concentration risk rather than eliminating it,” Wilkes noted. “The best enterprise strategy is not to search for another Hugging Face, but to separate model discovery from model custody. We can continue using Hugging Face to discover and evaluate models while mirroring approved models into an internal repository or registry under our control.”

Risk of increasing AI control by Nvidia

IDC’s Ashish Nadkarni, a group VP, said CIOs must also remember that the Nvidia move could give it various levers to even further tighten its control over global AI developments. 

“Hugging Face is like GitHub for AI. It is the default front door for open AI innovation: it’s where data scientists, machine learning engineers, and developers discover pretrained models, fine-tune them, and push them into production, or find open datasets to train their own models,” he said. “Owning that front door gives Nvidia a major position in the mindshare of today’s AI development personas.”

Consultant Brian Levine, executive director of FormerGov, also advised CIOs to stay alert. He predicted that Nvidia will exert greater control over Hugging Face efforts, but it will happen so gradually that it might not be noticed.

“The risk isn’t a dramatic reverse course. It’s a slow drift, where the Nvidia-optimized path quietly becomes the easy path, and everything else becomes the friction path,” he said. “Stop treating Hugging Face as a vendor-neutral utility and start treating it as a strategically-owned platform. That doesn’t mean leave. It means keep your options real and tested, not theoretical.”

Unanswered questions

And, from an enterprise CIO’s perspective, there’s another worry.

“Nvidia’s openness commitment is precise where it is cheap, and silent where it is expensive,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “The release promises that Nvidia compute will not be required, that multi-cloud and multi-accelerator support continues, and that developers choose their own models, each of which is a commitment about availability rather than about terms. Nothing in it addresses ranking, search placement, or default routing, and those are what decide which models a developer ever sees. Nobody has to be banned for the field to tilt. Gravity is enough and gravity is the part the pledge does not mention.”

This article originally appeared on InfoWorld.

Citrix on Tuesday announced that it has completed the acquisition of longtime partner Numecent, producer of technology that containerizes and manages Windows applications.

The acquisition builds on joint efforts to integrate Numecent’s management tool, Cloudpager, with Citrix Desktop-as-a-Service (DaaS) after an integration announced in April let administrators natively publish and manage the application containers through familiar Citrix workflows.

Numecent’s other product, Cloudpaging, packages Windows applications into isolated application containers independent of the underlying operating system, streaming them to Windows endpoints on demand rather than requiring them to be included in a desktop image. 

Citrix plans to further integrate the technology into its platform, while also continuing Cloudpaging and Cloudpager support for physical Windows devices.

“Enterprise customers have told us for years that application management is one of the most painful parts of running a Windows environment,” said Shawn Bass, SVP and GM of Citrix DaaS, in the announcement of the acquisition. “Numecent has solved this in a genuinely elegant way. By bringing Cloudpaging and Cloudpager into Citrix, we can make this capability native to every DaaS and physical desktop deployment so IT teams get back the time they spend wrestling with images and app conflicts.”

Analysts and consultants said the move will help enterprise IT to some extent, but will also increase vendor lock-in with Citrix while potentially exposing enterprises to data security risks.

Good for Citrix customers

Gartner VP Analyst Stuart Downes said, “overall, this is a positive for Citrix customers,” but he stressed that the promised conversions “are not 100% compatible.” 

He said, “low-level integrations into the kernel are generally not successful” because code that needs the lowest level of OS integration usually needs direct links to the hardware. Still, he estimated that applications at the low level probably account for only 2% of enterprise applications. 

For the more typical apps, Downes said that there will likely be “north of 90% compatibility. It varies. There are quite a lot of complex factors in app virtualization.” But he emphasized that Numecent offers two components: Cloudpager and Cloudpaging, and “we have yet to see how Citrix will integrate both.”

Justin Greis, CEO of consulting firm Acceligence, also sees a lot of potential savings for the enterprise.

“Large companies can have thousands of Windows applications, including legacy, custom, industry-specific, and highly specialized applications,” he said. “Many have dependencies on particular versions of Windows, libraries, configurations, or desktop images. Every major desktop refresh, Windows migration, VDI program, cloud move, acquisition, or infrastructure modernization effort can therefore create another application testing and repackaging cycle. The ability to abstract more of the application layer from the environment underneath it can remove a meaningful amount of that friction.”

Noah Kenney, principal consultant at Digital 520, added that the theoretical advantage that Citrix can now offer has great enterprise potential.

But, he argued, this likely amounts to an enterprise IT pay less now, pay more later situation.

“There are operational savings here, which is why customers will adopt it, but the bill comes due when they try to leave,” Kenney said. “This is a good acquisition for Citrix and probably bad for enterprise leverage over time. Citrix can now lose the desktop and still keep the customer. Every application moved into Cloudpager raises the cost of the next migration. Customers get the simplification now and Citrix gets the switching cost later.”

Half right

Sanchit Vir Gogia, chief analyst at Greyhound Research, said that he reads the containerization pitch as half right. “The packaging premise is valid. The cross-operating-system execution premise is not,” he said.

Gogia pointed out that Numecent Cloudpaging packages a Windows application with its dependencies and streams it to a Cloudpaging Player on a physical or virtual Windows endpoint, where it executes locally. “A Mac or Linux user reaches that application through Citrix’s remote delivery, where it still executes on Windows. That is cross-platform access, not cross-platform execution,” he said. “A Windows application does not become a Mac application merely because its pixels arrive on a Mac. The container is a packaging promise and the boundary of that promise is Windows.”

That said, he noted that there is still a lot of value in the Citrix arrangement, because Cloudpaging separates an application from a particular Windows image and carries that package across physical and virtual Windows environments, including Arm-based devices. 

“The real advance is not escaping Windows,” Gogia explained. “It is making application change less dependent on desktop change. Microsoft’s own App Assure data puts enterprise application compatibility above 99.7%, and Cloudpaging’s commercial logic lives almost entirely inside the fraction that remains. At enterprise scale, the final 1% of applications can carry far more than 1% of the business risk.”

But, he added, “Existing Numecent customers need binding answers on entitlements, migration and exit. Citrix has bought control of a useful Windows application lifecycle. Control now has to prove itself, and the proof it owes customers is less complexity, not merely more control for Citrix.”

Possible risk

However, consultant Brian Levine, executive director of FormerGov, pointed out that the nature of these new Citrix capabilities could expose users to serious security issues, including the risk of data exfiltration. 

He sees Cloudpager as “essentially a privileged switch that can push software to every Windows endpoint at once, which is precisely the kind of mass-distribution channel that produced SolarWinds and Kaseya. Bolting it onto Citrix, whose NetScaler gear has been a favorite ransomware target through repeated ‘CitrixBleed’ flaws, may leave CIOs and organizations wondering who will focus on security for the combined entity, and how will it prevent the type of attacks we’ve seen against Citrix.”

Citrix was asked to comment on these security questions, but did not do so by publication time. 

This article originally appeared on Computerworld.

Companies grow in many ways, and physical security must keep pace. Sometimes growth occurs naturally through the evolution of internal business programs, but other times one company grows by acquiring another one, and it’s often a company that’s very different from the one that’s doing the acquiring. Growth is exciting, but with growth through acquisition, security teams face challenges around integrating two sets of dissimilar systems, processes, org charts and security cultures. These planning tips should help keep you agile and prepared when your security team encounters acquisitional growth.

Converging to an integrated roadmap

When one company acquires another, there’s an inevitable mismatch between security programs and plans. Company A might have mature processes but outdated systems; Company B might have recent tech but few processes for integrating its use. Or the companies might have different deployment and application philosophies. Sometimes the company being acquired has no formal physical security program at all.

The security culture at each company can also clash: one uses phone-based mobile credentials, while the other uses proximity access cards; one is rigorous about securing its IP due to strict regulations, while the other can historically afford to be more casual. These disconnects intensify when the acquired company’s people aren’t motivated to adopt the policies and practices of their acquirer.

Guess what? Very soon, they’ll all need to play together as one organization. And if one or both of the companies has an existing security technology roadmap, they each face inheriting various aspects of the other’s strategy. For all plans to work together and operational continuity to be preserved throughout the change, security leaders must find some way to blend the two companies’ strategies and cultures to yield an integrated plan for common platforms, activities and standards across the newly unified team.

Elevating security visibility

For most of us, corporate mergers and acquisitions (M&A) seem to happen fast — sometimes without warning. The decision to merge with or acquire another company is typically made in corporate boardrooms, beyond the consideration or awareness of individual departments. As senior executives meet to discuss fine print and calculate bottom lines, they don’t always account for the true costs of merging teams, resources and processes at the operations level, including IT, facilities management and security.

During acquisitions, then, security needs to play a role in shaping change, not just executing it. The number one way to accomplish this is to identify the committee in your company that manages M&A-related changes and do what you can to make sure security is on it. With security leaders adding their voice, you’ll face fewer roadblocks and misfires as acquisitions proceed.

As due diligence proceeds in the wake of an acquisition announcement, it’s up to the security team to provide its own accounting and plans, so that budget and support are hopefully available to accommodate the transition. This means jockeying for visibility as decisions get made that impact the efficacy of security operations and the protection of the newly merged physical environments.

Four areas to focus on

Why does visibility matter so much for security during acquisitional due diligence?

First of all, this work matters because cost and scope assumptions regarding security systems and personnel that are made without security leadership present are doomed to be woefully inaccurate. But also, merging security programs often incurs expenses that go way beyond traditional personnel and technology costs: SME travel during due diligence and integration, retraining of personnel, support for new users and so on. The transition team might be aware of some of these costs, but security can be there early on to make a holistic case by showing cost models, gap analyses and other key roadmap elements.

Planning and positioning your new security journey along this blended route is a matter of examining each company’s current security program and finding effective ways to integrate each one with the other — including potentially sunsetting certain program elements by evaluating and selecting the ones that work best in the new organization.

Correlation must happen across four main areas — budget, technology, people and culture. Let’s take a look at some high-level guidance in each area to help you get started. Then, we’ll jump into three key scenarios to see the areas where emphasis is especially needed to achieve smooth results.

Correlation area #1: Budget and business integration

In many ways, roadmapping starts and ends with a budget. If you don’t have funding, you can’t provide security on the level you plan for. If you don’t work with your M&A committee to identify and amplify security considerations in your blended roadmap, you’ll miss the chance to get your share of budget up front. Be prepared with security budget items and ready to defend them. Need to consolidate and integrate massive security solutions at both companies? Find out now, not later, and obtain the funding you need to get it done.

At the same time, educate yourself on the relative security postures of the two companies, and seek to strengthen your overall posture where needed. Incoming business units often push back on requests for funding, and the security team at the acquiring company must be prepared. The best way is to be backed up by the right corporate policies and directives that reinforce security standards and put the burden on the acquiring company to ensure compliance. Lacking this leverage, the security team has very little leverage to get the business units to spend money.

Wielding emotional intelligence to keep productivity on track

Acquisitions are a time of heightened emotions, and morale can be sharply affected, particularly at the company being acquired. Simultaneously, the security program integrations that acquisitions entail often expose new, temporary security vulnerabilities.

The most success with positive morale and productivity occurs when both companies are intentional about understanding each other’s position. The acquiring company succeeds with diplomacy, helping the new teammates understand the WHY of certain changes rather than just steamrolling in to implement them. Including this “why” perspective will help prioritize integration activities with minimal disruption in a sometimes-fragile transition.

Meanwhile, the acquired company succeeds by finding power in its more modest position, showing up in good faith, knowing its questions will be heard and answered.

Correlation area #2: Technology and infrastructure

The nuts and bolts of merging security at two companies often come down to how you’ll overlay the tech components — primarily your access control and video surveillance platforms, but also the other systems, platforms, applications, network appliances and other technologies that support security at your sites. It also helps to have the annual costs of operating your security program ready to share, as you might discover opportunities for savings as you go along, such as lowering operating costs by eliminating redundant server resources and application licenses.

Ultimately, your goal is to retrofit and standardize systems across two — or sometimes more — environments. In the course of doing this, you’re likely to uncover gaps and mismatched elements that will take time and money to fix. In some cases, the whole platform at your company or the one you’re acquiring might be so close to end-of-life that the acquisition is actually a chance to wipe the slate clean and start over. Make sure your M&A committee understands the importance and nuances of your concerns and has visibility and clarity on your proposed approach.

Correlation area #3: People and roles

Role redundancy is usually what people fear most when they hear their company is undergoing M&A. The axe can fall pretty hard in some acquisitions, depending on how similar the roles and procedures are in each environment. Security is no exception. As soon as you can, you’ll want to carefully document teams, roles, duties and job descriptions at both companies to check for overlaps and gaps.

But don’t make assumptions too fast. You won’t know exactly how many people are needed until you’re crystal clear on the direction your new roadmap is taking. In some cases, so-called redundant personnel can be retrained, reassigned or even promoted based on revisions you make to integrate operations.

Use your voice on the M&A committee to make your personnel expectations clear. No matter the outcome, you’ll benefit from having a clear sense of each company’s security team and how their methods of providing security services compare.

Correlation area #4: Culture

Security culture is a vital consideration for acclimating newly merged companies to one another. The characteristics of a company’s culture drive the way it does business, and when one company acquires another, those cultures have the potential to clash.

Some large companies have been so stung by this reality they’ve made cultural association a deciding factor over others in whether to acquire a company or to alternatively continue growing some other way.

At companies that acquire or are acquired, these culture clashes can impact a physical security program in various ways. Users at smaller companies acquired by larger ones sometimes feel like “Big Brother” is watching them, whereas they formerly operated with less electronic oversight. If the security team at an acquired company has less sophisticated platforms and processes, they can feel overwhelmed by the need to upgrade both and adjust their approach. Change management is essential for addressing these issues and providing a unified security culture at the resulting merged company that everyone feels a part of.

Navigating security culture differences

Acquired companies often feel bombarded with integration requirements, including many that don’t match up with the security culture they’re accustomed to.

To help ease these differences, enable the business, and reduce the stress of change, both companies’ integration teams should ensure security leadership from both sides is engaged, not just the acquiring company, while helping the security team itself adjust to the increased risks it often faces as part of becoming a larger brand or differently focused operation.

Preparing for the scenarios ahead

Budget, technology, people and culture provide the foundation for aligning security programs during acquisitional growth. However, the way these areas are addressed will depend on where the organization is in the acquisition process. A company preparing for possible growth will face different priorities than one responding to an acquisition already underway or managing acquisitions as an ongoing part of its business.

As an aviation industry veteran with over 30 years of experience, Alaska Airlines CIO Charu Jain is all too familiar with the technology integration process that often follows a big airline merger.

By her count, she’s been involved in four such projects. But none, she says, has brought her greater satisfaction than leading the overhaul of Alaska’s PSS following its $1.9 billion acquisition of Hawaiian Airlines in September 2024.

“This is one of the biggest milestones in any merger work done between airlines,” says Jain, speaking from her company’s Seattle offices just two months after Alaska and Hawaiian completed their transition to a shared PSS.

In its simplest terms, a PSS is an all-encompassing software suite used by airlines to record and manage a passenger’s journey, from booking tickets and checking in baggage at the airport, to boarding the aircraft and accessing the in-flight menu. “A PSS touches almost every function of an airline from employees to guests,” says Jain.

Two brands, one system

At the time of the merger, Alaska and Hawaiian each had its own PSS. No sooner had the ink dried on the deal than the cutover project got underway to bring both airlines’ systems under a single operating platform.

According to Jain, the two airlines agreed from the get-go that they’d retain their own unique historic brands, both with a combined history of close to 200 years, which would be reflected through the system.

“It had never been done before, developing capabilities to enable two brands on one platform,” adds Jain, who also serves as Alaska’s SVP of merchandising and innovation. “We didn’t want a situation where a passenger travelling from Spokane to Seattle on an Alaska-branded flight, and then onto Honolulu on a Hawaiian-branded flight, would have to navigate two separate systems. So we thought about how to make that experience more seamless.”

After settling on a PSS, developed by travel software manufacturer Sabre, Jain and her colleagues began work on migrating the airlines’ millions of bookings and passenger information, while also updating their various guest- and employee-facing tools for the new system.

Selling cutovers and mock flights

Executing a system cutover on such a large scale is a delicate balancing act, not least in a live-environment where, for a major airline, any form of disruption to the passenger experience can be bad for business. So there was no attempt to rush the project.

“To make sure we didn’t have any issues with customers’ bookings, we really took a risk-optimized approach with a phased deployment and a phased cutover,” says Jain.

Much of this hinged on what Alaska refers to as a selling cutover. Starting in October last year, all new bookings were made on the new PSS, which allowed the group to drain old bookings from the legacy system, and start selling tickets six months in advance of the official transition date; the average booking curve for an airline is around six months.

“There was no migration of millions of records and bookings,” says Jain. “This meant when our customers checked in on the first day [of the PSS], it was as if the booking had been made on the native system.”

While this was going on, however, Alaska was hit by a sizeable IT outage that grounded flights across the country and impacted the travel plans of nearly 50,000 passengers. It followed a previous IT outage in July. However, Jain says the disruptions didn’t impact the project in any way.

So in the final months leading up to the cutover completion, Alaska carried out several dress rehearsals to test the system, including mock flights for domestic and international routes in anticipation of the recent launch of several non-stop services to Europe.

This involved real guests arriving at the airport, completing check-in, going through security, and taking their seats as if they were about to take off. Leaving no stone unturned, the simulation also accounted for baggage collection, pets, wheelchair users, and onboard hospitality, stopping just short of passengers being served actual food.

Alaksa completed five such mock rehearsals in all. “The fifth one was when everything worked without any medium or high issues, and gave us the confidence we were ready,” says Jain.

As part of the airline’s scenario planning, it also set up command centers in various locations, including Honolulu and Seattle, to plan for unforeseen and unrelated problems on the day of the cutover.

A dedication to collaboration

A project is only ever as a good as its people, and Jain is quick to hail the collaborative spirit that Alaska and Hawaiian brought to the table. As a PSS involves both the operational side of an airline’s business — touching on everyone from pilots, flight attendants, and baggage handlers — and commercial departments responsible for policies and pricing, this was more than a purely technological undertaking.

“This was about people coming together from two companies to make this one big thing happen,” says Jain.

When Alaska started making bookings on the new PSS last fall as part of the selling cutover, it also began training employees how to use system. It was around that time as well, says Jain, that the airline was confident the transition would be completed by April 2026, just in time for the busy summer travel season.

Since the PSS has been up and running, the company has also introduced a single mobile app to replace Alaska and Hawaiian’s separate existing ones, allowing passengers to personalize their experience to the airline brand they’re more familiar with.

“It’s a much more seamless experience now that there’s no confusion knowing which app to go on, or why they have two booking numbers,” says Jain. Alaska’s employees are also just as happy with their new tools, she adds.