VCF 9 License Files: Connected vs Disconnected

Archive update (November 2026): This article describes VCF 9.0 registration files as observed in June 2025. The decoded JWT payload may contain opaque fields whose contents cannot be independently verified from that decoded view alone. Do not submit real registration files or environment metadata to third-party AI decoding services. For current licensing procedures, refer to Broadcom KB 437242 (VCF/VVF 9 licensing) and VCF 9.1 licensing changes.

In this article we take a closer look at what information is shared — and when

In the transition from traditional license keys to file-based licensing, VMware Cloud Foundation 9 (VCF) has introduced a new model that not only modernizes the process but also makes it more transparent. Whether you’re registering your environment in a connected mode (where information is sent over the internet) or disconnected mode (offline file upload), you might wonder: What exactly is inside this file? And what is shared with VMware?

Whether Connected or Disconnected, License Management is Easy!

Let’s take a closer look. For the purpose of this article, I went into the License Management – Registration area of VCF Operations 9 and selected the “Download Registration File”, which then presented me with a file it named:

Registration-AAA-BBB-CCC-DDD-EEE.example.net-2025-06-17T04_05_31Z.data

And my first thought was, “Hey, what exactly AM I UPLOADING?!”

This file uses a JWT (JSON Web Token) format — a widely adopted open standard that encapsulates structured metadata in a secure, signed package.

Just google “jwt decode” or paste the block into your favorite AI tool and have it decode! That’s how easy it is to see the contents!

What stood out was how clearly the contents were laid out. After decoding the JWT, it became obvious that the file:

Clearly shows the model version, asset name, and type
Includes timestamps, request IDs, and UUIDs
Contains no secrets, passwords, or environment-sensitive details
Presents one field (xr2) that appears to contain compact, encoded metadata likely used for licensing validation or asset fingerprinting

Here’s a sanitized example of what that decoded content might look like:

{
  "model_version": "1.0.0",
  "asset_name": "aaa-bbb-ccc-ddd-eee.example.net",
  "created_on": 1750133131.6168032,
  "asset_type": "AC",
  "xr2": "<base64-encoded block of environment metadata>",
  "asset_id": "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "request_id": "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

In other words:

You can inspect most of what’s being sent — and see exactly what’s included.

The file is readable, compact, and verifiable. Even though the xr2 field is encoded and potentially encrypted or signed, it’s intentionally structured, minimal in size, and purpose-built to transmit only what’s necessary — nothing more.

This is true whether you upload the file manually (disconnected mode) or allow it to register and refresh automatically (connected mode).

And here’s where it gets interesting: at first glance, you might lean toward disconnected mode — especially if you’re cautious about what’s being transmitted. But just like the early days of DRS and vMotion, many of us remember when every single migration or decision required manual approval. We didn’t trust the automation — until we did.

We’d hover over every vMotion like a nervous parent on a bike ride without training wheels. But with time — and repeated success — we embraced the trust. Eventually, we moved to fully automated DRS, because it just made sense. It worked, and we didn’t need to micromanage.

The same idea applies here. While disconnected mode offers a controlled, inspectable process up front, connected mode ultimately provides:

No repeated manual uploads
No license refresh cycles every 180 days
A seamless experience where registration and updates just work

In both models, the file remains structured and minimally scoped. Connected mode just reduces the effort — without increasing the risk.

Gone are the days of:

Buried license keys
Hidden metadata
Opaque activation processes

This shift to file-based registration helps both customers and support teams understand exactly what is being used, when the file was created, and what will be submitted.

Why this matters

Transparency leads to confidence. When tools use readable, industry-standard formats like JWTs, it:

Makes it easy to confirm what’s being shared
Supports disconnected environments where privacy matters
Enables automation, documentation, and support alignment

For customers managing highly-regulated, air-gapped, or enterprise-scale environments, this simplified, readable licensing model brings both peace of mind and operational efficiency.

Where to Learn More

You can explore the full documentation and registration workflow here:

? Register VCF with File-Based Licensing – Broadcom TechDocs

Final Thoughts

By adopting file-based licensing, VCF isn’t just solving a technical problem — it’s providing clarity and predictability. Whether you’re online or offline, the file you generate is straightforward, verifiable, and under your control.

And if you start disconnected but grow more comfortable over time, know that moving to connected registration is less about giving up control — and more about reducing operational overhead, just like we did with DRS.

This is the kind of transparency we like to see in enterprise IT.

Have questions about what’s inside a license file or how connected vs. disconnected licensing works? Let’s connect and discuss.

This post is part of the “Architect’s Edge Insights” series — designed to help unpack and simplify VMware Cloud Foundation topics. Check back regularly for new breakout articles that bring clarity to technical transitions, operational best practices, and strategic guidance across your VMware investments.

To Learn More Check out the LATEST on VCF 9.0 Licensing here at TechDocs!

Originally published on LinkedIn on June 17, 2025. This copy preserves historical statements and references as published; they have not yet been reassessed for current accuracy.