Cloud has become the operating backbone for satellites and pavement sensors, for economic data and air traffic, for grants that shape bridges and ports. As agencies layer AI, edge and soon quantum on top of multi‑cloud environments, the benefits will undeniably include speed, scalability and resilience. But a shadow can grow alongside them in the form of fragmented data, inconsistent governance and rising operational risk. In a session titled “The Cloud Has a Shadow” at this year’s GBEF EDGE Security Summit, Dave Barber of SAIC, Brian Epley of the U.S. Department of Commerce, and Daniel Morgan of the U.S. Department of Transportation unpacked how they addressed those shadows. Others, including autonomy and unmanned systems leaders, can learn key lessons from their experiences.
Lesson #1: Start With Mission, Not Platforms
Cloud strategy begins with mission, not with infrastructure diagrams or provider comparisons. Epley anchors conversations in what Commerce is actually trying to accomplish. For his department, that includes national economic security across “13 colonies,” independent bureaus ranging from satellites and fisheries to patents, trade and census.
That pavement test segment marked “USDOT test section,” with 50 years of performance data and photographs behind it, provides a good example. The only way to make decades of imagery and measurements usable to engineers worldwide is to put that dataset into cloud‑based platforms where it can be queried, visualized and combined with other infrastructure data. In other words, cloud is how DOT turns its operator, investor and steward responsibilities into living, accessible systems instead of static archives.
Autonomy and infrastructure stakeholders who compile rich historical data on everything from roadworthiness insights for automated vehicles to better targeting of drone inspections on aging assets, are also moving to the cloud. Those cloud decisions should be judged by whether they improve mission outcomes in the form of safer operations, better data, faster response and more resilient services.
Lesson #2: Name Fragmentation As The Shadow
Epley described Commerce as “my 13 colonies,” a metaphor for a department where each bureau has built successful but highly independent technology stacks. “Each of the 13 colonies have succeeded on their individual missions, but that’s the ceiling of where we’ve been,” he said. The shadow here is fragmentation. Different clouds, different controls and different ways of handling data and risk make it harder to act as a unified enterprise.
Morgan described the same pattern at DOT. In pursuit of “the right cloud for the right workload,” agencies have adopted multiple infrastructure‑as‑a‑service and software‑as‑a‑service providers. That useful flexibility also slices the data estate into pieces and creates new seams where visibility and defense become more difficult. “If we enter those clouds individually as one of our 13 colonies, it becomes exponentially harder for us to have the data fluidity that we need to make our decisions,” he warned, noting that DOT depends heavily on Commerce’s data for transportation decisions.
In autonomy, fragmentation can also show up as separate silos for flight telemetry, sensor payloads, maintenance records, and regulatory reporting. Naming that shadow is the first step toward treating multi‑cloud as an asset instead of a liability.
Lesson #3: Build The Harness Before The Engine
Epley warned, “We have to build the harness before we build the engine.” The harness is his term for an enterprise foundation that embeds governance, security and data standards without leading with them. It is the shared architecture that lets a bureau take advantage of a cloud provider while allowing others to inherit controls, logging and data access when they follow.
This is the heart of his OneCommerce vision. Rather than thirteen different ways of doing the same thing, Commerce is building common operating capabilities so subsequent bureaus entering a particular cloud can “assume and inherit all the controls and the governance and realize the benefit of the data as an asset that’s there.” The payoff will be less re‑work, more reuse and more time spent on innovation instead of repetitive operations and maintenance.
For autonomy and unmanned systems, “the harness” might involve shared identity and access patterns, common logging and observability tools, and enterprise data models that span UAS operations, ground robotics and infrastructure analytics. Engines such as new AI models, new mission apps and new sensor types are easier to swap in and scale when they clip into a stable harness.
Lesson #4: Turn Standards Into Execution
Commerce has a unique asset in NIST, which Epley likened to having a heavyweight colony like Massachusetts inside the department. NIST produces standards and special publications that shape AI risk management, post‑quantum cryptography and enterprise cyber risk. However, he stressed that these only truly matter when they become operational practice. “We need to bring those standard special publications directly in line with our mission and that’s the execution arm,” he said.
He shared a recent example where NOAA needed a new way to reach a cloud service provider. Instead of simply approving or rejecting the idea, Commerce invited NIST and other bureaus to shape the approach together. The group moved quickly, and the resulting pattern now serves as a foundation that other “colonies” can adopt. It is a concrete case of standards driving execution rather than sitting on a shelf.
For autonomy ecosystems, standards for UAS operations, data exchange, and safety are essential, but their real value comes when they inform tenancy design, data pipelines and the way multiple clouds handle mission data. When teams treat standards as tools for building shared infrastructure, the shadow of fragmentation gets smaller.
Lesson #5: Do Not Just Move The Mess Faster
Under federal mandates to exit data centers, DOT has been aggressively re‑hosting systems into cloud environments. Morgan acknowledged that some workloads simply have to move to meet deadlines, and those re‑hosts can unlock new licensing models and metrics based on the provider. But he was adamant that migration alone is not modernization. “We don’t necessarily want to take the same thing we currently have and put it in the cloud. We’re not trying to do a dumb thing faster,” he said.
Instead, DOT is layering product thinking on top of its infrastructure decisions. The goal is not just to run the same system in a new place, but to converge on the best product for each mission domain. That usually means learning from different “colonies” inside DOT, sharing what works and retiring redundant or outdated approaches.
It is tempting to call any lift‑and‑shift to cloud an upgrade, but if the result is the same brittle workflow sitting behind a different URL, the mission has not improved. The better question is: does this move make operations more reliable, data more usable, and decisions more timely?
Lesson #6: Aim For “Demos, Not Memos”
Morgan also offered a mantra that could easily apply across autonomy and defense tech: “demos, not memos.” He sees cloud and AI tools as ways to iterate faster with mission partners and show value in working systems rather than static documents. In his view, the next generation of cloud should help make “easy things easy so that people can pull value from us to get their missions done.”
Stakeholders who live in the mission (pilots, field teams, city planners, emergency managers) do not need more memos about multi‑cloud strategy. They need better dashboards, faster analytics, cleaner operational pictures and systems that handle complexity for them. Quick, safe demos can build trust in new cloud‑based autonomy services far more effectively than documents alone.
Lesson #7: Measure Success In People, Not Platforms
The closing exchange brought the conversation back to the human impact. Asked what might be top of mind a year from now, Morgan resisted specific predictions but hoped agencies would be focused on delivering technology at the pace their mission partners require. He wants to see an environment where it is easy to pull value from systems, not just receive deliveries labeled “done.”
Epley widened the lens. He described today’s work as “building the future of the next 250 year experiment” and reminded the audience that his identity as a technologist is secondary to the mission’s impact on the American people. Technology, in his view, is an enabler and a catalyst, not the goal.
In autonomy and unmanned systems, this may be the most important lesson of all. Multi‑cloud strategies, AI tools, and emerging platforms are only meaningful if they make skies safer, infrastructure more resilient, communities better protected and decisions more grounded in reality. When leaders keep those outcomes in view, the cloud’s shadow becomes something they can manage rather than something that erodes trust.