This past weekend, I was at Hersheypark as a chaperone for my son’s middle school band trip. As I wandered around the park listening to him and his friends talk complete gibberish, laugh at things that made absolutely no sense, and just enjoy life without a care in the world, I found myself being pulled back to when I was that age.

Back to the days when responsibility barely existed. Back to the feeling of freedom, whether it was real or not. Back to when life felt incredibly simple.

As I watched hundreds of school kids walking around the park, from middle school all the way up to high school age, it suddenly hit me just how far removed I am from that stage of life. Not in a bad way, just in a very real way.

Then, a few days before that, I was standing at the soccer field watching my son’s team, listening to a couple of parents talking about how old they felt. The funny part was that none of them were older than 35. I have to admit that made me chuckle a bit. It was another one of those moments where I realized, “Yeah… I really am at a different stage of life now.”

Now this is not some dramatic “woe is me, I am old” moment. Far from it. I know plenty of people significantly older than me who are still active, sharp, driven, and enjoying life. This is more about the realization that I am now at that age.

• Old enough to be the dad of almost all the adult players on both of my soccer teams.
• Old enough to have married, kids, and grandchildren.
• Old enough that when younger parents talk about feeling old, I just smile quietly to myself.

Yet mentally, in many ways, I still feel like my almost 14-year-old son running around Hersheypark with his friends.

Now, admittedly, the body does not always agree with me on that one. Recovery takes longer than it used to. Random aches appear for no reason whatsoever. Injuries somehow happen while sleeping. But overall, I am genuinely grateful. I am grateful to still be fit and healthy enough to do the things I love.

• I can still play and coach soccer.
• I can still mountain bike, run, hike, and stay active.
• I still have the energy to keep up with life, family, work, and the endless chaos that comes with all of it.

As I thought about all of this, I found myself asking a pretty simple question:

“Am I happy with where I am?”

Of course, there are things I could improve. There are things I wish I had done better. There are areas where I still need to grow as a husband, dad, friend, coach, and person in general. That never really stops.

But overall? Honestly, yes. I am happy with life.

I have an amazing wife whom I love more than anything. I genuinely do not know where I would be without her. She has supported me, grounded me, encouraged me, and probably pushed me when I needed it most. Looking back, a huge amount of where I am today is because of her influence, guidance, patience, and belief in me.

I have fantastic kids that I am incredibly proud of, even if they occasionally do completely ridiculous things. But that is part of growing up. We all did stupid things at some point.

I love what I do for work. I am grateful that I have been able to build something that gives me flexibility and allows me to work from home and be present for my family. That is something I never take for granted.

Overall, I am simply grateful for where life is right now.

As I look around at friends my age who are also reaching this point in life, I think this stage is less about getting older and more about reprioritizing. It is about figuring out what really matters. It is about recognizing that time moves faster than we think. It is about understanding that change is not always a bad thing.

Sometimes the next chapter is the exciting part.

So, as a few of us step into this half-century stage together, I think it is time to celebrate it, not dread it. Time to embrace whatever comes next. Time to enjoy the next phase of family, friendships, adventures, and life in general.

• There is still a lot left to do.
• Still places to go.
• Still memories to make.
• Still goals to chase.
• Still adventures ahead.

So to my fellow half-century friends, here’s to the next 50.

Although developers still run familiar commands such as build, serve, and package-solution, the underlying system executing those commands has changed. HEFT now orchestrates the entire toolchain behind the scenes. Understanding its workflow does not require deep technical knowledge of its internal configuration files. Instead, it requires understanding how HEFT structures work into phases and tasks, how it relies on the SPFx rig, and how it executes plugins in a predictable order.

The Foundation: Phases and Tasks

HEFT organizes work into phases, and each phase contains one or more tasks. This structure replaces the older script-driven approach previously used in SPFx.

A phase represents a logical stage in the build lifecycle. For example, there are phases for building, testing, and packaging. Each phase defines what types of work must occur at that stage.

Inside each phase are tasks. A task performs a specific responsibility, such as compiling TypeScript, processing Sass, running tests, or bundling assets. Tasks are implemented through plugins and are executed in a defined sequence.

This structured model means that HEFT does not simply run commands in order. Instead, it evaluates the current phase, identifies the tasks attached to it, and executes them according to the configuration defined by the SPFx rig and your project’s configuration files.

The SPFx Rig: Where the Defaults Come From

Every SPFx project references a rig configuration. The rig defines the default build behavior for SharePoint Framework projects.

The SPFx rig specifies:

• Which phases are available
• Which tasks belong to those phases
• Which plugins implement those tasks
• The default configuration for those plugins

Because your project references the rig, you inherit a complete build pipeline without having to define it manually. This is important because it ensures consistency across all SPFx projects and allows Microsoft to evolve the toolchain while maintaining compatibility.

When HEFT runs, it first loads the rig configuration, then applies any project-level configuration overrides. This layered approach ensures that the default pipeline remains stable while still allowing controlled customization.

What Happens When You Run a Build Command

From a developer’s perspective, building an SPFx project looks straightforward. You run a command such as npm run build. However, under the hood, HEFT follows a structured process.

• First, HEFT loads your project configuration and resolves the rig reference. This tells HEFT which phases and tasks are available for execution.
• Next, HEFT activates the requested phase. For a standard build, this is the build phase. The build phase contains tasks such as TypeScript compilation and asset processing.
• HEFT then executes the tasks in the order defined by the rig. For example, TypeScript compilation must complete before bundling can occur. If a task fails, HEFT stops the phase and clearly reports the error.
• Once compilation and preprocessing tasks are completed successfully, HEFT invokes the bundling step. This uses webpack internally, but HEFT controls when and how webpack is executed.
• After bundling completes, HEFT produces the expected output artifacts, such as compiled JavaScript and processed assets.

Because the workflow is defined declaratively, every execution of the build phase follows the same sequence.

A Simple Practical Example

To make this clearer, consider a basic SPFx web part project created with the standard generator.

The project includes:

• TypeScript source files
• SCSS styles
• A manifest file
• Static assets

You run the build command.

Here is what HEFT does conceptually.

• HEFT reads your project configuration and determines that it is an SPFx solution using the SPFx rig. It activates the build phase defined in that rig.
• The first task compiles TypeScript files. If there are type errors, the build fails at this stage.
• Once TypeScript compilation succeeds, HEFT runs the Sass processing task. Styles are transformed and prepared for bundling.
• Next, HEFT runs the webpack task. The webpack configuration is generated according to the SPFx rig. If you have not customized it, the default configuration is used. Webpack bundles your solution into optimized output files.
• Finally, HEFT completes the phase and produces the build output.

At no point are you writing custom build scripts or manually chaining tasks. The entire workflow is orchestrated through phases, tasks, and configuration.

Included Plugins in the Workflow

HEFT uses plugins to implement tasks. The SPFx toolchain includes built-in plugins for common activities such as:

• TypeScript compilation
• Sass processing
• Jest testing
• Webpack bundling
• Running additional scripts

Each plugin is responsible for one aspect of the build. HEFT coordinates them rather than embedding their logic directly into the core engine. This plugin model improves modularity. If a plugin needs to be configured, you modify its configuration file. If a new capability is required, it can be added as a separate plugin instead of rewriting the pipeline.

How Custom Code Fits into the Workflow

The workflow also allows custom logic through documented extension points. If you need to run custom code during the build, the Run Script Plugin lets you register a script file to execute in a specific phase. HEFT treats that script as part of the pipeline.

If you need to adjust how webpack behaves, the Webpack Patch Plugin lets you modify the generated webpack configuration before bundling. Both mechanisms operate within the structured phase and task model. They do not replace the pipeline. They integrate into it.

This design preserves stability while allowing flexibility.

Migration Context: From Gulp to HEFT

In the previous Gulp-based toolchain, developers commonly modified gulpfile.js to inject custom behavior. That approach relied on imperative scripts and custom task definitions.

The HEFT model replaces that with:

• Configuration-driven phase definitions
• Plugin-based task execution
• Structured extension points

The migration documentation emphasizes that although the underlying orchestration system has changed, the user-facing experience remains familiar. Developers still use standard commands, and SPFx projects still produce the same outputs.

The key difference is how those outputs are generated and managed internally.

Why This Workflow Is Important

The HEFT workflow improves predictability and maintainability. Because tasks are explicitly defined and executed in known phases, the build process is easier to reason about.

This structured approach also improves reliability in automated environments such as CI/CD pipelines. The same phase-based workflow runs locally and in build agents, reducing discrepancies between development and production builds.

Most importantly, the workflow is designed to evolve. Since tasks are implemented through plugins and configured declaratively, improvements to the toolchain can be delivered through updated rig definitions rather than rewriting individual projects.

Conclusion

HEFT’s workflow in SPFx is built around clear phases, modular tasks, and configuration-driven execution. When you run a build command, HEFT loads the SPFx rig, activates the appropriate phase, executes its tasks in order, and produces predictable output.

Although the visible developer experience has not changed dramatically, the underlying orchestration model is significantly more structured than before. That structure is what enables safer customization, smoother upgrades, and long-term sustainability for SPFx solutions.

The traditional approach has been B2B guest invitations. You invite the user, they accept, and they show up in your directory as a guest. It works fine for a handful of people. At scale, though, it becomes a mess. Attributes drift. People leave the source organization, and their guest accounts linger. Display names go stale. Someone has to manually track all of it, and that someone is usually you.

Microsoft Entra Cross-Tenant Synchronization (CTS) is the automated solution to that problem. Instead of managing guest accounts by hand, you configure a provisioning engine to handle creation, updates, and removals automatically.

So What Is It?

Cross-Tenant Synchronization is a feature of Microsoft Entra ID that automatically provisions and manages users across two separate tenants. You have a source tenant where your users live, and a target tenant where you want those users to appear. CTS keeps the two in sync without you having to do anything manually once it is set up.

It is built on the same provisioning engine that Microsoft uses for automated user provisioning to SaaS applications. If you have ever configured app provisioning in Entra ID, the concepts will feel familiar. If you have not, do not worry about that yet. The important thing to understand right now is that this is not a one-time operation. It is an ongoing, automated relationship between two tenants.

What Can It Do?

The most obvious thing CTS does is create users in the target tenant based on what exists in the source. When you add someone to the sync configuration, they are automatically provisioned in the target. No invitation required, no manual steps, no waiting on end users to accept anything.

Beyond creation, it keeps user attributes up to date. Things like display names, job titles, departments, email addresses, and manager information stay consistent across both tenants as long as the sync is running. If something changes in the source, it flows through to the target on the next cycle.

It also handles deprovisioning. When a user leaves scope, either because they left the organization or because you removed them from the configuration, they get removed from the target tenant as well. That alone is a significant improvement over the traditional guest model, where stale accounts often stick around long after they should have been cleaned up.

Users appear in the target tenant as B2B collaboration users. By default, they are created as external members rather than external guests, which means they behave much more like internal users across Microsoft 365 workloads. They show up in Teams directories, they have broader access to SharePoint, and they generally run into fewer friction points day to day. You can configure them as guests if that suits your environment better, but member is the default for good reason.

What About Different Cloud Environments?

Standard CTS works within the same Microsoft cloud. Commercial to commercial, or GCC-High to GCC-High. But Microsoft also supports synchronization across different cloud environments, which opens things up considerably.

You can synchronize identities between a commercial tenant and an Azure Government tenant, or vice versa. You can also go between commercial and the 21Vianet cloud used in China. This matters a lot to organizations that operate across both commercial and government environments, which is more common than you might think, particularly in the defense and federal contracting space.

The configuration for cross-cloud synchronization follows the same general pattern as the same-cloud setup, with a few additional steps to establish trust across the cloud boundary. I will cover that in detail in a later article.

Why Does This Matter?

The short answer is that it removes a significant amount of manual work and replaces it with something reliable and consistent.

If you have been managing guest accounts across tenants by hand, you know how quickly it becomes a problem. Users change roles, and their guest profile in the other tenant still shows their old job title. Someone leaves, and their guest account sits there for months. A new person joins, and someone has to remember to send them an invitation, hope they accept it, and then manually verify that the attributes look right.

CTS takes all of that off your plate. Once it is configured, it runs on its own. Accounts get created when they should, updated when they should, and removed when they should. The tenants stay consistent without requiring ongoing manual effort to maintain that consistency.

It also benefits the users themselves. With automatic invitation redemption, they do not have to take any action to appear in the target tenant. Access just works. That is a much better experience than receiving an invitation email, clicking through a consent prompt, and hoping everything is set up correctly on the other side.

For organizations running multi-tenant environments, whether that is due to a merger, a regulatory requirement, or just the way things grew over time, CTS gives you a foundation for managing identities that actually scales.

The root cause is rarely the technology itself. It is almost always the approach taken to designing Conditional Access.

At a high level, most organizations fall into one of three patterns.

• Some treat Conditional Access like a set of firewall rules.
• Others organize it around user personas.
• The more mature environments evolve further, using risk and real-time signals to make decisions dynamically.

Each approach has value. Each also has limitations. The real goal is not to pick one but to understand how they fit together into a scalable model.

The Starting Point: Thinking in “Firewall Rules”

It is completely natural to begin by treating Conditional Access like a firewall. For years, that is how access control worked. You defined rules based on conditions, and the system enforced them consistently.

In this model, Conditional Access policies are built around straightforward logic. If a user connects from outside a trusted network, require MFA. If a sign-in comes from a high-risk country, block it. If an application is sensitive, add an extra layer of authentication.

There is a certain clarity to this. It is easy to explain, easy to implement, and aligns with how many administrators have been trained to think about security. In fact, Microsoft’s own baseline recommendations encourage this kind of thinking early on, especially when enforcing MFA and blocking legacy authentication.

The issue is not that this model is wrong. It is that it assumes the environment is static.

Users no longer behave in predictable, fixed patterns. They move constantly between locations, devices, and networks. A user signing in from a different country might be traveling or an attacker. A device might be inside the corporate network but completely unmanaged. A trusted IP range might include compromised endpoints.

What begins as a small set of rules often expands into a large and fragmented collection of policies. One policy for location, another for applications, another for device state, and more to handle exceptions. Over time, it becomes difficult to determine which policy is actually enforcing what behavior. Troubleshooting becomes reactive rather than intentional.

More importantly, this approach does not truly understand the user. It focuses on where the request comes from, not on who is making it or how risky it is.

To make that distinction clearer, it helps to contrast how this approach behaves compared to more modern designs:

That limitation is what drives the next stage of maturity.

Shifting the Perspective: Designing Around Personas

As environments grow, organizations begin to recognize that not all users should be treated the same. A global administrator logging into the tenant carries a very different level of risk than a standard employee checking email. A contractor who has access to a limited set of resources should not be governed by the same policies as a full-time employee.

This is where persona-based Conditional Access design comes into play.

Instead of building policies around conditions alone, policies are built around identity roles and responsibilities. Users are grouped into logical personas, and each persona is assigned a consistent set of controls.

For example, administrators might be required to use strong, phishing-resistant authentication methods and access systems only from compliant devices. Standard users might have a balanced set of controls that enforce MFA without introducing unnecessary friction. Guests might be restricted to browser-based access with tighter controls around data movement.

This shift changes how policies are structured. Rather than a scattered collection of rules, you begin to see a layered model emerge. There is a baseline that applies to everyone, and then additional policies that apply based on the user’s identity.

The benefit here is not just improved security. It is clarity.

Policies become easier to read, audit, and explain. When something breaks, you can trace it back to a persona rather than digging through dozens of overlapping conditions. Governance improves because the design is intentional rather than reactive.

However, persona-based design still has a limitation. It assumes that users behave consistently within their roles.

An administrator is always high-impact, but a standard user is not always low-risk. A compromised standard account can be just as dangerous when used to move laterally or access sensitive data. Likewise, a legitimate admin performing routine work should not always be subjected to maximum friction.

That is where the most advanced approach comes in.

Moving to Adaptive Security: Risk-Based Conditional Access

The most mature Conditional Access designs move beyond static definitions entirely. Instead of relying only on roles or predefined conditions, they incorporate real-time risk signals into every access decision.

Microsoft provides these signals through identity protection capabilities. Sign-in behavior is continuously analyzed for patterns such as impossible travel, unfamiliar locations, unusual application access, or indicators of compromised credentials. Each authentication attempt is assigned a risk level, and Conditional Access policies respond accordingly.

This allows access decisions to become dynamic.

A user signing in under normal conditions, from a familiar device and location, may experience little to no friction. The same user, attempting access from a suspicious location or exhibiting unusual behavior, may be required to perform additional authentication or be blocked entirely.

What makes this powerful is not just the increased security, but the balance it creates. Instead of applying strict controls universally, security is applied where and when it is needed.

To better understand how these three approaches differ in practice, the comparison below highlights how each one handles core decision-making:

This approach aligns directly with Zero Trust principles. Every request is evaluated independently. Trust is not assumed based on past behavior, and access is continuously reassessed.

Of course, this model introduces new considerations. It requires the right licensing, integration with identity protection services, and ongoing monitoring to ensure that risk signals are accurate and meaningful. It also requires a shift in mindset, moving away from static rules toward adaptive decision-making.

But when implemented correctly, it represents a significant step forward in both security and usability.

Why No Single Approach Is Enough

It might be tempting to view these approaches as competing models, but in practice, they are stages in an evolution.

Firewall-style policies provide the foundation. They establish baseline protections and address the most obvious risks. Persona-based design brings structure and aligns policies with how organizations actually operate. Risk-based controls add intelligence, allowing decisions to adapt in real time.

A well-designed Conditional Access strategy combines all three.

At the base, you enforce universal protections such as MFA and blocking legacy authentication. On top of that, you layer persona-specific controls that reflect the different levels of access and risk across your user population. Finally, you introduce risk-based policies that dynamically adjust enforcement based on behavior and threat signals.

This layered approach is what allows Conditional Access to scale without becoming unmanageable.

What Microsoft Best Practices Emphasize

Across Microsoft’s guidance and the broader security community, a few themes consistently emerge.

The first is that baseline protections are essential. Every environment should enforce MFA, block legacy authentication, and protect privileged accounts. These are not advanced configurations; they are foundational requirements.

The second is that identity must be the primary focus. Network-based thinking does not translate well to cloud environments. Trust cannot be based solely on location or IP address. It must be based on who the user is, the state of their device, and the associated risk of their activity.

The third is the importance of simplicity and clarity. Overly complex policies are difficult to maintain and even harder to troubleshoot. A smaller number of well-designed policies is far more effective than a large number of granular rules.

Finally, there is a strong emphasis on testing and iteration. Conditional Access policies should be deployed in report-only mode first, validated with test users, and gradually rolled out. This reduces the risk of unintended consequences and ensures that policies behave as expected.

Bringing It All Together

The evolution of Conditional Access mirrors the broader shift in security. It starts with control. Simple rules, clearly defined boundaries, and predictable behavior. Then it moves toward understanding. Recognizing that users are different, that roles matter, and that policies should reflect that reality. Finally, it becomes adaptive. Decisions are made in real time, based on context, behavior, and risk.

The organizations that succeed with Conditional Access are not the ones with the most policies. They are the ones with the most intentional design.

They do not ask, “What rule should we add next?”
They ask, “What decision are we trying to make, and what information do we need to make it correctly?”

That is the difference between managing access and truly controlling identity.

And in a world where identity is the new perimeter, that difference is everything.

From that vision, Berryville FC was born. Now, as we move into the next stage of our journey and publicly rebrand as Summit Valley United, our mission has only grown stronger. And this year, more than ever, we need partners who believe in what we are building.

WHERE WE STARTED

We began with almost nothing:

• No home field
• No uniforms
• No sponsors
• No guaranteed roster
• No reputation

Just commitment, effort, and a desire to create a true soccer environment for local players. We practiced wherever we could find space. We funded everything ourselves: training equipment, league fees, even soccer balls. Every season came down to personal sacrifice and belief. But the players kept showing up. The team kept growing. The mission kept advancing.

WHERE WE ARE NOW

Today, everything looks different because the hard work paid off, and the club has grown far beyond its early beginnings. We now have the foundation, structure, and ambition to operate at a higher level. This spring, we are preparing two competitive adult teams, including a UPSL Premier side, to represent our club in national-level competition. These environments demand real commitment, financial stability, proper equipment, trained staff, and the discipline to run the club professionally.

At the same time, we are building the next major step in our journey: the launch of the Summit Valley United Academy in Fall 2026. This will introduce high-level youth travel teams designed to elevate players across our entire region. It will not be recreation soccer, nor a casual training option. It will be structured, development-focused, and aligned with long-term pathways that prepare young athletes for high school, college, and even adult competitive play.

With our rebrand to Summit Valley United, we now carry a real regional identity that reflects where our players come from and who we represent. Our footprint reaches across Northern Virginia, the Shenandoah Valley, the Eastern Panhandle of West Virginia, and even parts of Maryland. We are united by geography and purpose, and our message: United | Resilient | Strong, captures exactly who we are becoming. With this growth comes incredible opportunity, but also a greater responsibility to provide a professional, stable, and meaningful environment for every player who wears our badge.

WHY WE NEED SPONSORS

Running a competitive club responsibly isn’t cheap. Every season involves major costs:

• League Fees
• Referee Fees
• Home Field Rentals
• Training Facilities
• Equipment (balls, goals, cones, and pinnies)
• Player Insurance
• Matchday Operations
• Coaching Development
• Youth Academy Launch Infrastructure
• Marketing, Media, and Live Streaming
• Uniform Packages and Warm-Ups

Until now, much of this has come out of pocket from leadership. To grow safely and sustainably, we need partners who believe in giving players in our region a real pathway to train, compete, and develop.

WHAT SPONSORS RECEIVE

This isn’t a donation. This is a partnership. Sponsors will potentially receive the following:

• Logo Placement on Kits
• Website and Social Media Placement
• Spotlight Posts and Cross-Promotion
• Brand Integration in Matchday Media
• Opportunity to Support Youth Programs
• Community Visibility Across Two States

Our teams compete against clubs across Virginia, Maryland, DC, and West Virginia, meaning your brand is traveling, seen, and respected across the region. As the youth academy launches, that visibility grows even more.

WHY NOW IS THE TIME TO JOIN US

2026 is a turning point. We’re not a startup club anymore. We’re not trying to “see if this works.” We know it works, and now we’re scaling. Your support will help us:

• Stabilize our adult teams
• Build the youth academy
• Invest in better training equipment
• Support players who cannot afford the full costs
• Build long-term infrastructure for the region
• Strengthen the next generation of talent

This is more than soccer. This is building a community. This is creating opportunities for players who have never had them before. If you’ve watched us grow or believe in what we’re trying to accomplish, we’d love to talk.

INTERESTED IN SPONSORING SUMMIT VALLEY UNITED?

Whether you’re a business owner, organization, or individual supporter, we have sponsorship levels for all budgets; from training shirt sponsors to premier jersey placements, from youth academy partners to community supporters.

• Let’s grow this together.
• Let’s elevate soccer in our region.
• Let’s build something that lasts.

Reach out to begin the conversation: REACH OUT

If you don’t want to sponsor, or it is not a great fit, but you feel you can donate to help as we continue to grow this year, then you can use this option: https://bit.ly/svu-donations

As the SharePoint Framework matured, however, that build system began to show its age. It worked, but it became harder to extend, harder to maintain, and increasingly difficult to modernize without breaking compatibility. To address these challenges, Microsoft introduced Heft as the new build orchestrator for SharePoint Framework projects.

You can learn more about Heft here: https://heft.rushstack.io

This article offers a high-level explanation of why Heft is used in the SharePoint Framework and how it improves the SPFx build experience.

The Role of a Toolchain in the SharePoint Framework

Before understanding Heft, it helps to step back and consider what a build toolchain actually does in the SharePoint Framework. When you run a command such as build, serve, or package-solution commands, a large number of things happen behind the scenes:

• TypeScript files are compiled
• Sass files are transformed into CSS
• Code is bundled and optimized
• Linting and validation rules may run
• Local development servers are started
• Assets are prepared for deployment

None of this happens automatically. A toolchain coordinates these tasks, decides their order, handles configuration, and ensures everything runs consistently across environments.

Historically, SharePoint Framework relied on Gulp as the main orchestrator. Over time, this led to a complex setup with JavaScript-based task definitions, custom scripts, and tightly coupled dependencies. While powerful, this approach also made the system fragile and difficult to evolve. Heft was introduced to solve those problems.

What Heft Is

Heft is a build orchestration system. It does not replace tools like TypeScript, Webpack, or Jest. Instead, it coordinates them in a structured, predictable, and configurable way. You can think of Heft as the conductor of an orchestra. The individual instruments (TypeScript, Webpack, Sass, ESLint) still do their own jobs, but Heft decides:

• When they run
• How they are configured
• How their outputs connect to one another

Rather than relying on handwritten JavaScript task files, Heft is driven primarily by configuration. This makes builds easier to understand, modify safely, and standardize across projects.

Why Microsoft Introduced Heft into the SharePoint Framework

The Legacy Toolchain Was Becoming Unmanageable

The original SharePoint Framework toolchain evolved incrementally over many years. Each new feature added another layer of configuration or scripting. Over time, this created:

• Hidden dependencies between tasks
• Complex Gulp pipelines that were difficult to reason about
• A higher risk of breaking changes when upgrading the SharePoint Framework versions
• Limited flexibility for customization without deep internal knowledge

Heft offered a way to reset the foundation without changing how developers build solutions.

A Shift Toward Configuration Over Code

One of the biggest philosophical changes Heft brings is the shift from configuration to custom scripts. In the older model, extending the build often meant writing JavaScript inside a gulpfile. While powerful, this approach has drawbacks:

• Scripts can conflict with internal logic
• Custom logic can silently break on upgrades
• Builds become harder to audit or standardize across teams

Heft replaces most of this with JSON-based configuration files that clearly describe intent rather than implementation. This makes the build pipeline more transparent and less error-prone.

Consistency Across Projects and Teams

Large organizations often struggle with building consistency. Two SharePoint Framework projects may look similar on the surface, but behave very differently under the hood due to custom scripts.

Heft promotes repeatable and predictable builds by encouraging teams to rely on shared configurations and standardized behaviors. This is especially important in enterprise environments where:

• Multiple teams contribute to the same tenant
• CI/CD pipelines must be stable
• Build behavior needs to be auditable and supportable long-term

Alignment with Modern Engineering Practices

Heft is part of a broader engineering ecosystem used internally by Microsoft and across many large-scale projects. By adopting it for the SharePoint Framework, Microsoft aligned SharePoint development with:

• Modern dependency management practices
• Structured build lifecycles
• Plugin-based extensibility models
• Long-term maintainability strategies

This alignment reduces the risk that the SharePoint Framework becomes isolated or outdated compared to other modern development platforms.

What Makes Heft Different from Gulp

While both Heft and Gulp can orchestrate tasks, they take fundamentally different approaches.

Gulp: Imperative and Script-Driven
With Gulp, developers define tasks using JavaScript. The build logic lives in code, and the order of operations is defined programmatically. This provides flexibility but also introduces complexity and risk.

Heft: Declarative and Configuration-Driven
Heft uses structured configuration files to define what should happen, not how to manually execute it. Tasks are modular, well-defined, and predictable.

This makes builds:

• Easier to understand
• Safer to customize
• More resilient to future changes

The Concept of Rigs in Heft

One of the most important ideas in Heft is the concept of a rig. A rig is a predefined build profile that describes how a certain type of project should behave. SharePoint Framework provides its own rig, which includes:

• Default build phases
• Standard plugins
• Expected behaviors for packaging and serving

By referencing a rig, a SharePoint Framework project automatically inherits a proven build configuration without copying files or scripts. This allows Microsoft to improve the build system over time while keeping projects stable.

Why This Matters to SharePoint Framework Developers

At first glance, Heft might seem like an internal change that does not affect day-to-day development. However, it has several real-world benefits for developers.

• Fewer Breaking Changes During Upgrades
  Because the build logic is centralized and standardized, SharePoint Framework upgrades are less likely to break custom build scripts. Developers spend less time fixing tooling and more time building solutions.
  
• Cleaner Project Structure
  Projects are easier to navigate because configuration files are explicit and purpose-driven. Instead of reading JavaScript build scripts, developers can inspect JSON files to understand behavior.
  
• Safer Customization
  When customization is required, Heft provides controlled extension points rather than unrestricted script access. This reduces accidental breakage and makes it easier to reverse changes.
  
• Better Fit for CI/CD Pipelines
  Heft’s predictable execution model makes it well-suited for automated builds, validation, and packaging in continuous integration environments.

Why Heft Matters to Organizations

For organizations that invest heavily in SharePoint Framework solutions, Heft delivers value that extends well beyond individual developer productivity. It introduces a more structured and predictable build foundation that supports long-term stability, governance, and scalability across teams and projects.

From a maintainability perspective, Heft helps reduce the accumulation of technical debt in build systems. By replacing ad-hoc scripts and tightly coupled task logic with standardized, configuration-driven behavior, solutions become easier to support and evolve over time. This is especially important for enterprise SharePoint Framework solutions that may remain in production for many years and must continue to build reliably as dependencies and environments change.

Heft also supports stronger security and compliance practices. Standardized build processes are inherently easier to review, audit, and secure than custom script-based pipelines. Because Heft favors declarative configuration over executable scripts, it reduces the likelihood of hidden or unintended behaviors running during builds, which is an important consideration in regulated or security-sensitive environments.

Finally, Heft improves knowledge transfer and team continuity. New developers can onboard more quickly because build behavior is explicit, consistent, and documented through configuration files rather than scattered across custom scripts. This clarity lowers the learning curve, reduces reliance on tribal knowledge, and makes it easier for teams to collaborate effectively on SharePoint Framework projects.

Heft as a Foundation for the Future

Heft is not just a replacement for Gulp. It is a foundation for how the SharePoint Framework evolves going forward. By moving to a modern, extensible, and standardized build orchestrator, Microsoft has positioned SharePoint Framework to:

• Adopt new tooling more easily
• Improve performance incrementally
• Support more complex enterprise scenarios
• Reduce friction for both developers and platform maintainers

This shift reflects a broader trend in modern development: simpler interfaces, stronger conventions, and clearer extension points.

Final Thoughts

Heft represents a significant but necessary change in how SharePoint Framework projects are built. While much of the functionality remains familiar, the underlying philosophy has shifted toward clarity, consistency, and long-term sustainability.

For developers, Heft means fewer surprises and more predictable builds. For organizations, it means better governance and reduced maintenance overhead. And for the SharePoint Framework platform itself, it means a healthier future built on modern engineering principles.

Understanding Heft is less about learning new commands and more about recognizing why the SharePoint Framework needed a stronger, cleaner foundation and how Heft provides it.

Microsoft Purview plays a central role in governing AI behavior, including Copilot’s interaction with external systems. Purview’s AI Hub adds a formal framework for identifying sensitive content, evaluating risk, enforcing safety checks, monitoring AI output, and validating whether Copilot-initiated actions comply with organizational policy. Securing plugins, agents, and connectors is not simply good practice; it is part of the broader AI safety architecture that Microsoft now expects organizations to adopt.

Understanding Copilot Extensibility Components

Before you can secure anything, you need complete clarity on what Copilot extensibility actually includes.

Graph Connectors

Graph connectors allow external data sources to be indexed into Microsoft Search and the Semantic Index. This makes the data discoverable to Copilot, meaning permissions, visibility, and indexing decisions directly impact AI behavior. Because connectors can introduce a large amount of previously siloed data into Copilot’s reach, they require strict scoping and careful review.

Agents

Agents are programmable constructs that can retrieve information, execute business logic, or call external APIs on behalf of a user. They extend Copilot from being a passive interpreter of content to an active participant in workflows. Agents must be treated as high-trust components because they can introduce new capabilities that Copilot would never have by default.

Plugins

Plugins extend agent behavior with additional actions or frameworks. They can provide two-way integration with external systems, enabling Copilot to query, create, or update data. Plugins sit at the intersection of identity, data access, and automation, which means improper configuration can lead to privilege escalation or unintended data movement.

Together, these components form the operational surface where Copilot interacts with information that goes beyond Microsoft 365. Each one must be governed tightly.

Risks Introduced by Extending Copilot

Microsoft’s AI security model makes one thing very clear: AI is not the risk; improper configuration is. Copilot adheres to all security controls, but plugins, connectors, and agents can expand that boundary if they are not adequately governed.

Key risks include:

• Broader data visibility through indexing external systems that were never intended to be searched.
• Privilege amplification if agents or plugins have more permissions than the users invoking them.
• Uncontrolled data movement if external APIs receive sensitive content without classification or protection.
• Inadequate auditing if plugin or agent activity is not captured in Purview’s recording pipeline.
• Shadow AI pathways if connectors surface content no one realized was accessible.

Microsoft Purview’s AI safety features, including output monitoring, risk analytics, and data classification enforcement, are explicitly designed to mitigate these risks. But the foundational responsibility remains in how organizations configure extensibility itself.

Securing Graph Connectors as a Copilot Data Boundary

Graph connectors widen the Semantic Index by introducing external datasets. If these datasets are not controlled, Copilot may surface or summarize information without the proper governance frameworks applied.

Essential Controls for Graph Connectors

Enforce Least Privilege
Connector identities must have only the permissions necessary to access and index the external content. Over-permissive service accounts immediately become AI exposure risks.

Validate Access Control Mappings
Connector ACLs directly determine who can search and, therefore, who Copilot can assist. Permissions must match the exact organizational structure of the external system.

Control What Gets Indexed
Connector indexing scopes should be configured to exclude content that is:

• Sensitive
• Unclassified
• Not governed under Purview policies
• Not intended for organizational search visibility

User-Level Permission Trimming Still Applies
Even with external data, Copilot respects the Microsoft Graph permission model. If a user cannot see a connector’s indexed item, Copilot cannot use it.

Monitor Connector Health
Connector logs, ingestion status, failed crawls, permission errors, and item counts should be part of your operational security checks.

Graph connectors are robust, but they fundamentally alter what Copilot can discover. Securing them is mandatory.

Securing Agents and Custom Actions

Agents introduce programmable logic into Copilot, allowing the AI to perform tasks that extend far beyond summarizing content or retrieving information. Because agents can call APIs, trigger workflows, or execute logic on behalf of a user, they must be governed with the same discipline applied to high-trust applications. Securing them begins with strict control over the actions they are allowed to perform. An agent should operate within a narrow and well-defined permission set, avoiding broad or unnecessary access to external systems. Over-permissioning is one of the fastest ways to expand Copilot’s reach unintentionally, so organizations must regularly review what each agent can do and confirm that its scope aligns with business requirements.

Administrative control is equally important. The ability to create, register, or update agents should only be granted to privileged identities protected by strong authentication, device compliance requirements, and Conditional Access controls. Because agents essentially introduce new capabilities into your AI ecosystem, their configuration must never fall into the hands of standard users or unmonitored service accounts. Purview’s auditing and monitoring tools become essential here, as every agent execution, external call, or data retrieval should be captured in logs. This provides traceability if an agent behaves unexpectedly or retrieves data it should not.

The organization should also validate output handling to ensure agent responses comply with corporate policy.

Microsoft Purview’s AI Safety controls help evaluate whether agent-generated content contains inaccurate details, sensitive data, or content that violates regulatory obligations.

By testing how an agent behaves in different scenarios, including edge cases, administrators gain confidence that it will operate safely once deployed. Securing agents ultimately means controlling their permissions, tightening their administrative boundaries, monitoring their actions, and validating their output through the broader governance framework Copilot relies on.

Plugin Governance and Data Flow Control

Plugins extend agent functionality and allow Copilot to interact with external frameworks or automation systems. Because plugins can initiate both inbound and outbound data flows, they require strong governance to prevent unintended information disclosure. Organizations must begin by establishing a controlled deployment model that allows only approved plugins to be used. This pre-approval process ensures each plugin undergoes a security and compliance review before it becomes part of the AI ecosystem. Once deployed, plugin usage should be restricted to specific roles or user groups rather than made universally available. Role-based assignment reduces exposure and keeps sensitive integrations out of reach of users who have no operational need for them.

Data security must be considered at every stage of plugin interaction.

Purview’s classification and labeling capabilities should be applied to data flowing into or out of plugin interactions, ensuring sensitive information is not inadvertently processed by external systems or returned in Copilot responses without proper protections. Equally important is output monitoring, which helps detect whether a plugin produces content that may contain regulated data, internal secrets, or unsafe operational instructions. This is especially relevant when plugins perform write operations or integrate with systems that store sensitive business information.

Continuous monitoring of plugin behavior is necessary to maintain governance integrity. Observing usage patterns, reviewing logs, and identifying anomalies help detect situations in which a plugin may be invoked unexpectedly or outside its intended workflows. Conditional Access also plays a role by blocking plugin use from high-risk sessions or unmanaged devices. By combining operational oversight, strict permissioning, strong data-handling controls, and session-level governance, organizations maintain predictable and controlled data flow across all plugin interactions.

Identity, Consent, and Administrative Controls

Any extension that interfaces with Copilot inevitably interacts with identity and permissions. Identity Hardening Requirements:

• Admin Consent for High-Risk Permissions
  Extensibility components should request only the permissions required for their function.
• Strict App Consent Policies
  Users should not be able to self-consent to plugins or agent integrations.
• Periodic Review of Connected Apps
  Administrators must regularly evaluate all registered connectors, plugins, and agents for permission drift or outdated configurations.
• Conditional Access for API and Graph Usage
  Use CA policies to restrict app and service principal access to compliant environments.

This ensures plugins, agents, and connectors never exceed their intended authority.

Validation, Testing, and Continuous Monitoring

Securing Copilot extensibility is not a one-time configuration exercise. Plugins, agents, and connectors introduce new operational paths through which data can move, actions can be executed, and systems can be influenced.

Because these capabilities extend beyond native Microsoft 365 workloads, organizations must adopt a rigorous validation and continuous monitoring approach.

Proper testing ensures that these components behave as expected under real-world conditions, respect the boundaries defined by your governance model, and do not accidentally expose sensitive information.

Validation begins with ensuring that data boundaries are enforced correctly. Administrators should test each connector, plugin, and agent under controlled conditions to confirm that they only access the datasets they were explicitly designed to interact with. For connectors, this means verifying that indexed content from external systems appears in Microsoft Search only for users with the proper access rights. For agents, administrators must confirm that actions remain restricted to their intended scope and that agents do not retrieve or generate information beyond the permissions assigned. Plugin validation should go further by evaluating not only the data retrieved but also how the plugin handles and returns output to Copilot.

Once initial validation is complete, organizations should conduct scenario-based testing to understand how extensibility components behave under different user profiles and security contexts. This includes testing what happens when:

• A user with minimal permissions interacts with a connector or agent
• A privileged user attempts to invoke high-risk plugin actions
• Conditional Access policies restrict specific actions or sessions
• Sensitive content is input into or returned from AI-driven processes

These tests can reveal weaknesses or unintended pathways that are not visible during normal configuration review. They also validate that the organization’s Purview controls, such as DLP, sensitivity labels, and safe output evaluation, are functioning correctly across the entire extensibility surface.

Continuous monitoring is essential because extensibility components evolve. Connector indexing patterns can change as external systems grow. API endpoints used by plugins may update. Agents may require new logic as workflows evolve. Without ongoing oversight, these changes can introduce blind spots in your governance model. Administrators should use Purview’s AI activity insights, audit logging, and classification-based monitoring to observe how Copilot interacts with extensibility components over time. These tools help detect anomalies such as unexpected data access, rapid increases in connector ingestion volume, or plugin outputs containing sensitive information.

Monitoring should also involve periodic review of app permissions and service principal access. Since connectors and agents rely heavily on identity and privilege mapping, permission creep can occur as administrators adjust roles, onboarding processes evolve, or APIs require expanded capabilities. Scheduled security reviews help ensure permissions remain aligned with least-privilege best practices and that no extensibility component gains rights beyond what is operationally necessary.

Organizations should incorporate red-team-style exercises to test the resilience of their extensibility governance against misuse or misconfiguration. These exercises can include simulating malicious prompts, attempting to exploit plugin functionality, or deliberately introducing misaligned permissions to validate whether Purview controls and DLP rules block unsafe operations. This type of testing verifies whether AI behavior remains inside the defined safety and compliance boundary even when confronted with adversarial or unexpected scenarios.

By combining structured validation, persona-based testing, continuous telemetry monitoring, and periodic security reviews, organizations create a resilient governance loop around Copilot extensibility. This ensures that connectors, agents, and plugins remain aligned to policy, behave consistently under stress, and maintain compliance with corporate and regulatory requirements as the environment grows and evolves.

Thoughts

Securing Copilot extensibility is not just about protecting external systems. It is about preserving the entire AI ecosystem inside your organization. Plugins, agents, and connectors extend the reach of AI, but they also extend your responsibility to enforce least privilege, monitor data flows, validate behavior, and apply continuous governance.

Microsoft Purview now provides the central control plane for AI safety, including content classification, output monitoring, risk evaluation, and compliance controls. By aligning your extensibility governance with Purview and Microsoft 365 security, you ensure that Copilot operates inside a secure, entirely governed, and intentionally defined boundary.

When these controls are correctly implemented, Copilot becomes a safe, predictable, and transformative capability. When ignored, extensions become the fastest path to unintended data exposure.

Under the hood, Copilot combines semantic indexing with Microsoft Graph to ground responses in your real content. This means that Copilot can provide more accurate and relevant insights because it understands not just what words are in your documents, chats, and files, but also how the content relates to your queries.

However, with great power comes increased responsibility. Because Copilot surfaces organizational data using the same index that powers Microsoft Search, this step is essential to ensure Copilot only sees what you intend it to see. Poorly governed search exposure means Copilot will faithfully reflect unintended access, overshared content, or improperly indexed data.

What the Semantic Index Is and How Copilot Uses It?

The semantic index for Microsoft 365 Copilot is a model trained on content from Microsoft Graph that enhances search relevance and accuracy while respecting your existing security, privacy, and compliance boundaries.

In practice, indexing translates organizational content into mathematical representations (vectors) that capture semantic relationships. This enables Copilot to provide results based on intent and contextual similarity; for example, linking terms like “USA,” “United States,” and “U.S.A.” because they share semantic meaning, rather than simple exact matches.

Microsoft builds these indices automatically for your tenant when you enable Copilot and assign at least one Microsoft 365 Copilot license.

Critically:

• The semantic index is generated from Microsoft Graph, which means it includes content from SharePoint, OneDrive, mailboxes, Teams, and other Graph-traceable sources.
• Permissions are respected at every level. Content appears in Copilot only if users already have access via Microsoft 365 permissions.
• The semantic index does not create new access rights or override any access controls in your tenant.

In essence, the semantic index is a high-performance retrieval layer that enhances Copilot’s understanding and response to user prompts while operating strictly within your established security boundaries.

The Link Between Microsoft Search and Copilot Access

Everything Copilot retrieves or interprets is governed by the same permission-trimmed index that powers Microsoft Search. Copilot does not maintain a separate index, nor does it bypass or override permissions. Its retrieval pipeline is built entirely on top of the Microsoft Search and Microsoft Graph security models, meaning Copilot will only surface content that a user is already allowed to access. This alignment is intentional and foundational to Copilot’s security posture.

At the core of this model are three principles:

• Permission trimming ensures a user only sees the content they already have access to, regardless of where it lives.
• Role-based access control determines what content is indexed and visible, based on Microsoft 365 and Microsoft Graph permissions.
• Personalization signals influence the order and relevance of results, based on user interactions, common collaborators, and organizational patterns.

The implications for Copilot are straightforward but extremely important. If a user cannot find a file, message, or site through Microsoft Search, Copilot cannot surface, summarize, or reference it. Conversely, if a user can discover something through Search, Copilot can use that content as part of its grounding and semantic interpretation.

Copilot also relies on Graph to validate user identity, map access tokens, and enforce security controls before retrieving any content. Every request Copilot makes must pass through these validation layers.

The AI never bypasses these frameworks and cannot elevate its own access based on prompts alone.

Because of this, Microsoft Search governance becomes Copilot governance. Oversharing in SharePoint becomes oversurfacing in Copilot. Broad group permissions become broader AI visibility. Clean, well-structured search boundaries produce clean, predictable Copilot outcomes.

The two systems are inseparably linked, and your Copilot readiness depends entirely on how well your search exposure is managed.

Controls That Manage Semantic Index Exposure

You cannot directly turn Semantic Index off, and Microsoft does not provide a standalone toggle to “hide from Copilot”, because exposure is governed by Search indexing and access controls.

Instead, you manage exposure using the following valid and supported controls:

SharePoint NoCrawl / Search Exclusion

SharePoint sites and libraries can be marked as Not indexed in Microsoft Search. This removes them from the tenant-level semantic index. Administrators can configure the “Allow this site to appear in search results” setting to No.

Permission Trimming and Access Control

Semantic index respects role-based access control. Users only see indexed content they have permission to access. This includes:

• SharePoint and OneDrive permission sets
• Exchange mailbox access
• Teams and channel membership
• Sensitivity labels with security restrictions

Sensitivity Labels and Encryption

Sensitivity labels with encryption and restricted extraction behavior feed into Microsoft Search’s filtering and indexing. While labels do not prevent indexing entirely, they can be used in combination with SharePoint’s search visibility settings to reduce semantic exposure.

Managing Copilot Connectors

Copilot Graph Connectors bring external content into your semantic index. These connectors inherit ACLs from the source system. If you misconfigure connector permissions, Copilot may index content that users were not intended to see. Administrators can review and adjust connector permission mappings via the Microsoft 365 admin center.

Validate Search and Semantic Index Exposure

Ensuring Copilot only sees the correct content requires structured testing. Because Copilot’s grounding mechanism relies entirely on Microsoft Search and Graph, the most accurate way to validate AI exposure is to validate search exposure.

The first step is to test Microsoft Search for each persona. Administrators should log in as standard users, department users, and high-privilege roles to search for sensitive areas such as HR libraries, executive documents, or financial reports. If a user cannot find the content through Search, Copilot will not interpret it. If the content appears, it is considered discoverable and must be addressed through access or indexing controls.

A second validation is testing Sensitivity Labels. Administrators should verify that encrypted or protected content is not returning in search results for unauthorized users, and that extraction-restricted labels correctly prevent Copilot from summarizing or generating content from those files.

Graph Connector visibility should also be evaluated. If external data sources are indexed, administrators should confirm that only intended users can see connector-fed items in search results. Overly broad connector mappings are a common source of unexpected AI exposure.

SharePoint’s “Check Permissions” tool remains critical. Because SharePoint access can be granted through inheritance, links, or membership in large groups, this tool provides a definitive view of who can see what. Any discrepancy between intended access and actual access becomes a direct Copilot exposure risk.

Finally, once indexing and permissions are validated, administrators should run controlled Copilot queries to confirm that the AI adheres to the search governance boundaries. This includes attempting to summarize sensitive files, querying protected areas, and validating that Copilot declines actions when it lacks the required access.

These tests collectively ensure the Semantic Index reflects your intended visibility model, not your accidental one.

Ongoing Governance and Index Hygiene

Semantic exposure is not static. As content grows, sites multiply, and teams evolve, the Semantic Index adapts automatically. This makes ongoing governance essential.

Administrators should regularly review newly created SharePoint sites to ensure they do not inherit overly permissive access. Many organizations unintentionally expose content by allowing new sites to be created without owners, without proper sensitivity labels, or with broad membership.

Group membership reviews should also be conducted routinely. Because many permissions derive from Microsoft 365 Groups and security groups, changes in group membership directly affect semantic visibility.

Graph Connector configurations require periodic auditing as well. External systems may shift, roles may change, or data structures may be updated. Each of these affects what gets indexed and how permissions are interpreted.

Search and Intelligence settings in the Microsoft 365 admin center should be monitored to confirm that verticals, result types, and indexing scopes align with organizational policies.

Finally, the broader governance ecosystem, including data classification, retention, sensitivity labels, and DLP, should continue to evolve alongside Copilot adoption. The stronger and more consistent your data governance program becomes, the more predictable your Semantic Index remains.

Ongoing governance is the only way to ensure that the AI continues to operate within a secure, fully controlled boundary as your data landscape grows.

Thoughts

The Semantic Index is one of the most powerful components of Microsoft 365 Copilot, enabling the AI to understand content through context, relationships, and meaning rather than relying solely on keywords. This capability delivers enormous productivity benefits, but it also increases the importance of maintaining strict control over search visibility and access boundaries.

Because Copilot depends entirely on Microsoft Search and Microsoft Graph for grounding, your search governance becomes your AI governance. Overshared files become discoverable insights. Poorly configured permissions become unintended AI visibility. Conversely, strong access controls, structured labeling, thoughtful indexing decisions, and disciplined permission hygiene result in a tightly governed and predictable AI environment.

By applying the correct controls, including search exclusion, permission trimming, sensitivity labeling, connector governance, and continuous auditing, you define a safe, intentional boundary for AI-driven interpretation. This ensures Copilot enhances productivity without exposing content that should remain private.

That drive started years ago as a teenager in the UK and grew stronger when my brother and I ran our own small record label, Kitschy Records.

https://www.beatport.com/label/kitschy-records/16169

At that time, we both spent a lot of time in music, learning, experimenting, and dreaming about what we could create. Even as life moved on and priorities shifted, that goal never really left me. Making music was always there in the background, waiting.

Fast forward to today, after many, many years of everyday life, I have released my first drum and bass album called “DIRECTION“, and it is now live on Spotify.

If vocal-driven drum and bass is your thing, I would love for you to check it out; if not, then no worries.

Understanding how CMMC 1.0, 2.0, and the forthcoming 3.0 compare is critical. It helps organizations assess where they stand, what their obligations are, and how to prepare for the next stage of compliance. In this article, we examine significant differences across versions and their implications for organizations, especially those that leverage Microsoft 365 and Azure.

Fundamental Differences: Structure, Scope, and Philosophy

Why the changes matter:

• The shift from 1.0 to 2.0 reduced complexity and aligned the model with standards such as NIST SP 800-171, easing compliance for small- and mid-sized contractors.
• CMMC 3.0 builds on this by emphasizing automation, modernization, and continuous assurance rather than static certification cycles.
• For cloud-enabled contractors, these changes reduce implementation overhead and align directly with tools already available in Microsoft 365 and Azure.

What Changed Between 1.0 and 2.0

The move from CMMC 1.0 to 2.0 represented a significant shift toward simplification and practicality.

Key differences include:

• Reduction in levels: CMMC 1.0 featured five levels, while 2.0 consolidated them into three levels: Foundational, Advanced, and Expert—to eliminate redundancy and confusion.
• Removal of maturity processes: The 1.0 model included process-maturity assessments that evaluated the extent to which cybersecurity practices were institutionalized. 2.0 eliminated this requirement to focus purely on control implementation.
• Introduction of POA&Ms: Plans of Action and Milestones allow organizations to document deficiencies and remediate them within a set timeframe, replacing the rigid “pass/fail” system of 1.0.
• Alignment with existing frameworks: CMMC 2.0 anchors Level 2 directly to the 110 controls of NIST SP 800-171, ensuring consistency across federal cybersecurity programs.
• Flexible assessment: While 1.0 required third-party certification at all levels, 2.0 allows for self-assessments at Level 1 and certain Level 2 contracts, reserving third-party reviews for higher-risk environments.

Impact for contractors:
CMMC 2.0 made compliance more attainable, especially for smaller suppliers in the Defense Industrial Base (DIB). Organizations can now leverage existing security investments, prioritize higher-risk areas, and progressively mature their programs without duplicating effort.

What CMMC 3.0 Brings

CMMC 3.0, still under development, is expected to refine rather than replace the 2.0 model. It focuses on enhancing clarity, aligning with the latest NIST updates, and embracing automation for continuous compliance.

Expected enhancements include:

• Updated baseline: CMMC 3.0 will align with NIST SP 800-171 Revision 3 and NIST SP 800-172, introducing updated controls and clarifying parameters for sensitive data protection.
• Outcome-based controls: Fewer but broader requirements focused on measurable outcomes, improving technical precision while reducing duplication.
• Emphasis on automation: The new version is expected to leverage automated control validation, continuous monitoring, and real-time evidence collection to replace periodic manual audits.
• Greater clarity and standardization: Updated guidance will reduce ambiguity in interpretations and ensure consistency across contractors and assessors.

What this means for contractors:
CMMC 3.0 represents an evolution toward continuous assurance. Contractors that adopt automated compliance dashboards, centralized log retention, and continuous validation on platforms such as Microsoft Defender for Cloud or Compliance Manager will be well-positioned to meet upcoming requirements.

Implications for Microsoft 365 and Azure Environments

For organizations using Microsoft cloud services, the CMMC evolution aligns naturally with built-in capabilities.

More precise mapping
Many of the NIST SP 800-171 and 800-172 controls map directly to Microsoft 365 and Azure services, including access management, encryption, and incident response.

Automation-ready architecture
Tools like Defender for Cloud, Purview, Sentinel, and Compliance Manager already support continuous monitoring, policy enforcement, and evidence generation; key capabilities for CMMC 3.0.

Reduced administrative overhead
With POA&Ms now permissible, cloud-native compliance tracking minimizes manual documentation while maintaining traceability for assessments.

Future-proofing
Organizations investing in automation, zero-trust identity governance, and centralized monitoring will be prepared for both current and forthcoming CMMC requirements.

Conclusion

The CMMC framework’s evolution reflects the DoD’s/DoW’s shift toward more innovative, scalable, and transparent cybersecurity oversight.

• CMMC 1.0 introduced the vision of structured maturity but proved too rigid and resource-intensive.
• CMMC 2.0 refined that vision, simplifying levels, removing unnecessary maturity layers, and aligning with trusted federal standards.
• CMMC 3.0 continues the evolution, focusing on automation, continuous monitoring, and modernized controls to keep pace with emerging threats.

For defense contractors, this evolution signals progress not just in compliance but also in operational resilience. Organizations leveraging Microsoft 365 and Azure already have the core tools to meet and maintain compliance through configuration, automation, and governance.

CMMC is no longer just a certification framework; it is a living model of cyber maturity. Adapting to its evolution ensures not only contract eligibility but also enduring trust, operational security, and alignment with national defense objectives.

Note

As of December 2025, the Department of Defense (DoD)/Department of War (DoW) has not formally released or announced an official version labeled “CMMC 3.0.” The current, legally recognized framework remains CMMC 2.0, codified in the final rule published under Titles 48 and 32 CFR on November 10, 2025. This rulemaking establishes the Cybersecurity Maturity Model Certification program as a mandatory requirement for specific defense contracts and begins a phased implementation period extending through November 2028.

While the DoD/DoW continues to evaluate updates to align future revisions of CMMC with NIST SP 800-171 Revision 3 and SP 800-172, there is no official release date, draft, or publication for any “CMMC 3.0” standard. References to CMMC 3.0 in public discussions reflect anticipated future modernization efforts, such as enhanced automation, continuous compliance monitoring, and improved control clarity. Still, these have not yet been formally adopted or implemented.

Until further notice, CMMC 2.0 remains the authoritative version, and all contractors should prepare for compliance with the requirements defined in the November 2025 final rule and the corresponding DFARS clauses.