OPA vs Enterprise OPA (EOPA)

Choosing a Policy Decision Point (PDP) is one of the first architecture decisions in Policy as Code — whether you are greenfield or replacing something else.

At a glance — default for new teams

Start with OSS OPA (CNCF graduated, Apache 2.0). EnforceAuth works identically with both PDPs — same Rego in Git, same bundle.tar.gz, same deploy pipeline.

Choose EOPA when a concrete requirement needs it: decision log masking at the PDP, delta bundles at large fleet scale, or bundle partitioning. You do not need EOPA to adopt Policy as Code or to use EnforceAuth.

Switching later is mostly a container image and config change — not a Rego rewrite.

Both run Rego and pull the same OPA bundle format EnforceAuth builds and publishes. EnforceAuth is the control plane for either PDP.

First time to Policy as Code?

Most teams landing here are not migrating from Styra or another OPA distribution. They are:

• Replacing scattered if role == admin checks with versioned Rego
• Standing up a PDP (sidecar, daemon, or centralized) for the first time
• Using EnforceAuth as the control plane from day one

For that audience, the decision is simple:

Your situation	Start with
New to OPA, standard authorization, tens of PDPs	OSS OPA
HIPAA/PCI-style rule: mask PII in decision logs before they leave your network	EOPA (or mask in PEP/proxy with OSS OPA)
Hundreds+ of PDPs, huge bundles, many deploys per day	Consider EOPA for delta bundles
One monorepo, many policy domains, fleet-level slice isolation	Consider EOPA partitioning (or separate bundle paths per system in EnforceAuth)

When in doubt, pick OSS OPA and revisit after you have traffic, bundle sizes, and compliance requirements in hand.

→ Continue with Getting Started with OPA and the 15-minute quickstart.

Historical context (Styra DAS™, EOPA)

Styra DAS™ was Styra's commercial policy control plane — decommissioned April 30, 2026.

Enterprise OPA (EOPA) was donated to the CNCF OPA project as an Apache 2.0 PDP subproject — masking, delta bundles, partitioning, and data-heavy integrations.

EnforceAuth is the enterprise authorization platform that operationalizes Policy as Code at scale: multi-tenant SaaS console, promoted environments, fleet monitoring, decision-log ingestion, MCP, and supported operations.

If you are migrating from DAS™ or an existing EOPA fleet, see Migrating from Styra DAS™ below — that is a subset of readers, not the default path.

Decision tree

flowchart TD
  A[Choosing a PDP] --> B{Must decision logs be masked before leaving your network?}
  B -->|Yes| EOPA[EOPA]
  B -->|No| C{100+ PDP instances with large or frequent bundle updates?}
  C -->|Yes, delta bandwidth matters| EOPA
  C -->|No| D{Need bundle partitioning across fleet segments?}
  D -->|Yes| EOPA
  D -->|No| E{Migrating from Styra DAS or existing EOPA fleet?}
  E -->|Yes| EOPA
  E -->|No| OPA[OSS OPA — default for greenfield]

Side-by-side comparison

	OSS OPA	Enterprise OPA (EOPA)
Home	open-policy-agent/opa (CNCF graduated)	open-policy-agent/eopa (CNCF OPA subproject)
License	Apache 2.0	Apache 2.0
Rego policies	Yes	Yes — same language
EnforceAuth bundles	Yes	Yes — same bundle.tar.gz format
Deployment patterns	Sidecar, daemon, centralized, SDK, gateway	Same patterns
Decision log masking	Redact in PEP, proxy, or custom pipeline	Native decision_logs.mask in PDP config
Bundle updates	Full bundle replace on poll; HTTP ETag caching avoids redundant downloads	Delta bundles — smaller incremental policy/data updates at fleet scale
Partitioning	Single bundle per PDP config (or separate paths per EnforceAuth entity)	Partitions — named slices from one release
Data-heavy policies	Custom plugins or push data into bundles at build time	Native datasource integrations (SQL, DynamoDB, Kafka, LDAP, S3, Vault, …)
Fleet resource profile	Production-grade at moderate scale	Tuned for large fleets and data-heavy evaluation (lower memory/CPU vs OSS OPA in EOPA benchmarks)
Typical starting point	Greenfield Policy as Code (default)	Regulated masking, very large fleets, partitioning
Commercial license	None required	None required for the CNCF-donated distribution

Industry context (2025–2026)

Relevant if you evaluated Styra in the past or inherit an EOPA fleet — not required reading for greenfield teams.

Event	What it means for you
Styra team → Apple (2025)	Styra no longer sells or supports products as an independent vendor
EOPA → CNCF OPA (2025)	EOPA is an open-source PDP subproject — not a Styra license SKU
Styra DAS™ decommissioned (April 30, 2026)	DAS™ control plane is end-of-life — migrate to EnforceAuth for enterprise policy lifecycle and fleet operations
EnforceAuth	Enterprise authorization platform — governance, promotion, audit, and fleet visibility
OSS OPA unchanged	CNCF governance continues; Apple does not own the OPA project

When OSS OPA is the right choice

• Greenfield Policy as Code — no legacy DAS™ footprint, no masking mandate on day one
• Standard authorization — RBAC/ABAC without data-heavy database integrations
• Small to medium fleets — tens of PDP instances, full bundle download is acceptable
• Simplest operations — openpolicyagent/opa image, largest community examples

OSS OPA is production-grade at scale (CNCF graduated). EnforceAuth customers commonly run OSS OPA sidecars in Kubernetes with bundles from S3.

When EOPA is the right choice

Decision log masking

Authorization input often contains PII — emails, SSNs, bearer tokens, internal IDs. OPA's decision log plugin ships evaluations to EnforceAuth for audit and coverage.

EOPA can redact JSON paths at the PDP before logs leave your network:

decision_logs:
  service: enforceauth
  mask:
    - "/input/user/email"
    - "/input/user/ssn"
    - "/input/request/headers/authorization"

With OSS OPA, we recommend masking in the PEP or a log proxy. For HIPAA, PCI, or strict data-residency rules, masking at the PDP is often a hard requirement — that alone can justify EOPA.

See PDP integration for a full EOPA config example.

Delta bundles

OSS OPA typically downloads the full bundle.tar.gz on each activation.

EOPA supports delta bundles — when only part of the policy tree changes, the PDP applies a smaller patch instead of re-downloading the entire artifact. This matters when:

• You have hundreds or thousands of sidecars polling the same destination
• Bundles are large (many services, shared data.json, WASM plugins)
• You deploy policy frequently (multiple times per day)

Bundle partitioning

Partitioning lets different PDP fleets subscribe to different slices of the same overall policy release — for example, payments partition vs catalog partition.

Use partitioning when one monorepo builds many policy domains but each service should only load its slice. OSS OPA can achieve similar isolation with separate bundle paths per EnforceAuth system entity.

Data-heavy workloads and fleet caching

EOPA targets enterprise PDP scale beyond what a minimal OSS OPA sidecar needs:

Capability	What it gives you
Native datasource integrations	Pull policy-time data from SQL, DynamoDB, Kafka, LDAP, S3, MongoDB, Vault, and more — without writing custom OPA plugins
Delta bundles	Smaller bundle activations across large fleets — less egress, faster rollouts after EnforceAuth deploys
Partitioning	Each fleet segment loads only its policy slice — less memory per PDP
HTTP bundle caching	Standard OPA ETag / If-None-Match behavior; EOPA's delta + partition model reduces how often full artifacts move when policies change
Vault-backed http.send	Secrets for external calls stay in your secrets manager

EnforceAuth still owns the control plane (Git → test → bundle → S3/GCS). EOPA owns runtime evaluation efficiency at the PDP. With EnforceAuth, point decision_logs and status at the platform — you do not need EOPA's Splunk/Kafka log sinks unless you also mirror logs elsewhere.

See EOPA introduction for datasource and performance details.

Migrating from Styra DAS™

For teams with an existing DAS™ or EOPA footprint only — skip this if you are new to Policy as Code.

Styra DAS™ was decommissioned April 30, 2026. DAS™ was the control plane — not the PDP. Most DAS™ customers ran EOPA (or OPA) on the data plane.

Control plane: Migrate DAS™ Git/deploy/decision-log management to EnforceAuth — enterprise policy lifecycle, multi-environment promotion, fleet monitoring, decision-log ingestion, and supported operations.

Data plane (PDP): If you already run EOPA sidecars or daemons:

• Keep EOPA initially — point bundle polling and decision_logs at EnforceAuth
• Rego is largely portable; review legacy builtins and data layouts from the DAS™ era
• Phased cutover: Migration from DAS™ / EOPA

Forcing a move to OSS OPA during a control-plane migration adds unnecessary risk. Choosing OSS OPA vs EOPA remains a separate decision — see the comparison table above.

What does not differ

Concern	Same for OPA and EOPA
EnforceAuth policy source (Git)	Yes
opa test in deploy pipeline	Yes
Bundle destination (S3/GCS/Azure)	Yes
API keys for decision_logs / status	Yes
PEP integration (POST /v1/data/...)	Yes
Rego you write in Git	Yes

EnforceAuth does not sit in the request path for either PDP. It governs lifecycle and evidence.

Deployment pattern is a separate decision

OPA vs EOPA answers which PDP binary. Sidecar vs host agent vs centralized answers where it runs. You choose independently.

Question	Guide
OPA or EOPA?	This page
Sidecar, agent, or centralized?	Deployment patterns
Wire app to PDP?	Application integration
Bundles + logs config?	PDP integration

Can you switch later?

Yes, in most cases.

1. Policies stay in Git — EnforceAuth rebuilds the same bundle
2. Change PDP image (openpolicyagent/opa ↔ EOPA build from open-policy-agent/eopa)
3. Add EOPA-only config (mask, partitions, delta) as needed
4. Rolling restart sidecars or daemons

Operations

Topic	OSS OPA	EOPA
License	Apache 2.0 (CNCF)	Apache 2.0 (CNCF OPA subproject)
Support	CNCF community + vendors	CNCF community + vendors
Image / binary	openpolicyagent/opa	Builds from open-policy-agent/eopa
Version pinning	Pin OPA release in manifests	Pin EOPA release from the CNCF repo

EnforceAuth does not resell or license either PDP. You choose based on features, not a separate EnforceAuth SKU.

Recommended next steps

If you chose…	Do this next
OSS OPA (most readers — including greenfield)	Getting Started with OPA → 15-minute quickstart → Deployment patterns
EOPA (masking, deltas, or partitioning)	PDP integration § EOPA → Deployment patterns
Migrating from DAS™ / EOPA fleet	Migration from DAS™ after PDP integration
Still comparing architecture	Your Policy as Code journey

Related guides

• Authorization engines landscape
• Getting Started with OPA
• Deployment patterns
• PDP integration