What do teams get wrong when they keep older policy models in a targetRef-based mesh?

A common mistake is keeping multiple policy styles alive after the platform has standardised on targetRef. That adds unnecessary complexity, makes policy intent harder to read, and slows adoption for new users. Teams should use the default targetRef model consistently so policy matching stays predictable and the operational model remains simpler.

Why older policy styles become a problem once a mesh standardises on targetRef

The main issue is not that the older models are unsafe in isolation, it is that they create two ways to express the same policy intent. In a targetRef-based mesh, that split makes policy harder to scan, compare, and reason about, especially when teams need to understand which workloads are actually in scope.

It also creates migration drag. New users learn the newer model first, while older policy shapes remain as exceptions that must be remembered, translated, and maintained. Over time, that slows adoption and increases the chance that teams carry forward patterns that no longer match the platform’s default operating model.

When policy syntax no longer matches the platform’s preferred abstraction, teams often end up optimising for familiarity instead of clarity. That is usually the point where policy reviews become slower and intent begins to depend on tribal knowledge rather than the mesh’s native matching model.

What breaks when multiple policy styles coexist

The practical failure is inconsistency. Teams may believe they are expressing one uniform access rule, but different policy styles can encode scope, attachment, and matching logic differently. That makes it easier for reviewers to miss gaps, especially when policies are distributed across multiple namespaces or owned by different squads.

Another problem is operational overhead. Mixed policy styles usually require more documentation, more exception handling, and more migration coordination. Instead of converging on one readable approach, teams spend time preserving compatibility between old and new policy authoring habits.

That overhead becomes most visible during onboarding, incident review, and change review. If operators have to ask which policy dialect a workload uses before they can interpret an authorization decision, the platform has already lost some of the simplicity that targetRef is meant to provide.

What teams should optimise for instead

The better pattern is to treat the default targetRef model as the canonical way to express policy in the mesh, then retire older forms deliberately rather than keeping them alive “just in case.” This makes policy matching more predictable and reduces the number of special cases reviewers must hold in mind.

Standardising on one model also improves governability. A single policy style makes it easier to write linting checks, create review guidance, and train new contributors on how attachment and scope are supposed to work. That matters because policy readability is itself a control: if teams cannot interpret policy quickly, they cannot govern it well.

For migration, the right sequence is usually inventory, translate, validate, and then deprecate the legacy style. The important point is to remove duality, not merely add support for a newer style while leaving the older one in active circulation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Mixed policy styles can weaken least-privilege clarity in mesh authorization.
	CM-2 — Baseline Configuration	A canonical targetRef model functions as the approved policy baseline for the mesh.
Recommendation — Standardize policy authoring to preserve least-privilege scope and reviewability. Define one approved policy baseline and retire legacy variants through controlled change.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication, and Access Control	Policy attachment and matching are access-control concerns that affect how workload access is governed.
Recommendation — Use a single access-control model so policy decisions remain consistent and reviewable.
ISO/IEC 27001:2022	A.5.1 — Policies for information security	The question is about keeping policy models coherent and manageable across the environment.
Recommendation — Consolidate policy structures into one maintainable policy standard and remove duplicates.
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Policy model standardization is a secure-configuration issue for the mesh platform.
Recommendation — Enforce one approved configuration pattern and remove legacy policy styles.

Practitioner Guidance

What to prioritise: Identify the policies that still use older syntax and decide whether they are truly required for compatibility, or just lingering from an earlier deployment phase. Legacy policy should be treated as technical debt with an owner, not as a harmless alternate style.

What to verify: Review whether policy intent remains identical after translation to targetRef, particularly for scope and attachment. Small differences in how a policy binds to workloads are where accidental exposure or over-restriction tends to appear.

Common mistake: Keeping the old model “for flexibility” while expecting operators to remember which style applies where. That usually produces more confusion than resilience, because readability and consistency degrade long before the old model is finally removed.

Practitioner takeaway: In a targetRef-based mesh, the goal is not backward compatibility for its own sake, it is a single, legible policy model that teams can review, enforce, and evolve without translation overhead.