The 3691 Framework: Engineering Security for the Composable Enterprise Architecture

Where the Composable Security Gap Shows Up

The composable enterprise architecture promises flexibility: teams pick best-of-breed components, swap them independently, and scale horizontally. But that modularity creates a security blind spot. In a traditional monolith, traffic flows through a controlled perimeter. In a composable setup, services communicate over APIs, event streams, and message queues—each a potential vector. We see this most acutely in organizations that have adopted microservices, headless commerce platforms, or event-driven architectures. The 3691 Framework emerged from observing real projects where security was treated as an afterthought, bolted on after deployment, leading to breaches that exploited inter-service trust.

Consider a typical e-commerce migration: a retailer decomposes its monolithic checkout into separate services for cart, payment, inventory, and shipping. Each team owns its component, deploys independently, and uses its own data store. The security team, still operating with a perimeter mindset, struggles to enforce consistent policies across these boundaries. An attacker who compromises the cart service can often pivot to payment by exploiting default service-to-service trust. The 3691 Framework addresses this by defining security boundaries at the component level, not the network edge.

The framework's name—3691—is a mnemonic for its three core principles: 3 layers of identity (user, service, data), 6 enforcement points (API gateway, service mesh, workload identity, policy engine, audit log, runtime monitor), and 9 verification steps in a continuous deployment pipeline. 1 stands for the single source of truth for policy. In practice, this means every component must authenticate and authorize every interaction, regardless of network location.

Teams that adopt this framework early in their composable journey avoid the costly re-architecture that comes from retrofitting security. The payoff is not just reduced risk but faster incident response: because policies are centralized and verifiable, teams can pinpoint the scope of a breach quickly.

Foundations That Teams Often Misunderstand

Identity Is Not Just for Users

Many teams start by implementing user authentication (OAuth, SAML) but overlook service identity. In a composable architecture, services need their own identities—typically via SPIFFE or mTLS certificates—so that the policy engine can distinguish between a legitimate payment service call and a compromised one. Without service identity, an attacker who steals a service token can impersonate any component.

Policy as Code Is More Than Config Files

Writing policies in YAML is only the beginning. True policy-as-code means versioning, testing, and reviewing policies through the same CI/CD pipeline as application code. Teams often treat policy as static configuration, leading to drift when developers bypass the policy engine for urgent fixes. The 3691 Framework mandates that every policy change goes through a pull request and automated validation, just like a code change.

Continuous Verification Replaces Trust on First Use

Traditional architectures often rely on trust-on-first-use (TOFU): once a service is authenticated, subsequent interactions are assumed safe. In a composable environment, that assumption is dangerous. The framework requires continuous verification—every request is checked against current policy, and any deviation triggers an alert or blocks the request. This is similar to zero-trust networking but applied at the application layer.

A common mistake is to implement continuous verification only for external-facing APIs while allowing internal service-to-service calls to bypass checks. Attackers frequently exploit this internal trust. The framework's design explicitly covers east-west traffic, which is where most composable breaches occur.

Patterns That Consistently Deliver Results

Identity-First Segmentation

The most successful teams start by mapping every component's identity requirements before writing any policy. They define which services can talk to which others, based on business function, not network topology. This segmentation is enforced at the service mesh or API gateway level. For example, a payment service should only accept requests from the order service, not from the frontend directly.

Policy-as-Code with Automated Testing

Teams that treat policies as code with unit tests and integration tests catch misconfigurations before they reach production. They use tools like Open Policy Agent (OPA) or Cedar to write fine-grained policies and run them in a simulator against sample requests. This pattern reduces the number of policy-related incidents by an order of magnitude.

Continuous Verification Pipelines

Embedding security verification into the deployment pipeline—not just scanning containers but also testing policy compliance—ensures that every release meets security requirements. Teams use canary deployments with automated rollback if a policy violation is detected. This pattern requires close collaboration between security and platform engineering teams.

We have observed that teams combining these three patterns achieve a security posture that scales with the architecture. The key is to implement them as a cohesive system rather than isolated tools.

Anti-Patterns and Why Teams Revert

Over-Engineering the Policy Engine

Some teams build a custom policy engine before understanding their actual threats. This leads to a system that is too complex to maintain, and developers bypass it by hardcoding exceptions. The result is a false sense of security. The fix is to start with a minimal set of policies—only those that address the highest-risk interactions—and expand iteratively.

Ignoring Developer Experience

If the security framework slows down development, teams will find ways around it. We have seen organizations where policy changes require a two-week review cycle, causing developers to merge code that violates policies and then fix it later. The anti-pattern is treating security as a gate rather than a partner. Successful implementations provide self-service tools, fast feedback loops, and clear error messages.

Assuming the Framework Covers Everything

No framework eliminates all risk. Teams that believe the 3691 Framework makes them invulnerable often neglect basics like dependency scanning, secrets management, and employee training. The framework is a complement to—not a replacement for—a defense-in-depth strategy.

When teams revert to monolithic security, it is usually because they tried to implement too much too fast, or they lacked executive buy-in for the cultural change required. The framework demands that security and development teams collaborate closely, which is a shift for many organizations.

Maintenance, Drift, and Long-Term Costs

Policy Drift Is Inevitable

As the architecture evolves, policies that were correct six months ago may become obsolete. New services are added, old ones are retired, and business requirements change. Without regular audits, policies drift from reality. The 3691 Framework includes a quarterly review cycle where teams compare policy intent against actual traffic patterns. Automated drift detection tools can flag anomalies, but human judgment is still required.

Cost of Continuous Verification

Continuous verification adds latency and computational overhead. Every request must be checked against the policy engine, which can become a bottleneck at high throughput. Teams need to invest in caching, policy distribution, and performance testing. Some organizations find that the overhead is acceptable for critical paths but not for low-risk interactions. The framework allows for tiered verification: high-risk operations get full checks, while low-risk ones use cached decisions.

Team Skill Requirements

Maintaining the framework requires engineers who understand both security and distributed systems. This combination is rare and expensive. Organizations often struggle to retain talent, leading to knowledge gaps. Cross-training and documentation are essential to mitigate this risk.

Despite these costs, teams that stay committed report that the framework reduces the mean time to detect (MTTD) and mean time to respond (MTTR) by providing clear visibility into service interactions. The long-term cost of not having such a framework—a major breach—is usually higher.

When the 3691 Framework Is Not the Right Fit

Small Teams with Simple Architectures

If your entire application runs on a single server or a few microservices with straightforward communication, the overhead of the framework outweighs the benefits. A simpler approach—like mutual TLS with basic access controls—may suffice. The framework is designed for complexity, not simplicity.

Highly Regulated Legacy Environments

Organizations in finance or healthcare that must comply with strict regulations (e.g., PCI DSS, HIPAA) may find that the framework's continuous verification model conflicts with audit requirements that expect static network segmentation. In such cases, a hybrid approach that uses the framework for new components while maintaining traditional controls for legacy systems is more realistic.

Organizations Without Security Engineering Support

The framework requires dedicated security engineering resources. If your security team is a single person who also handles compliance and incident response, implementing the full framework will stretch them too thin. A phased adoption—starting with identity-first segmentation, then adding policy-as-code later—can work, but the full framework is not advisable without a team of at least three security engineers.

We have also seen teams abandon the framework after a merger or acquisition, where the acquiring company's security model is incompatible. In those cases, it is better to align with the parent organization's standards than to maintain a separate framework.

Open Questions and FAQ

How does the framework integrate with existing SIEM/SOAR tools?

The framework's audit logs and policy decisions can be fed into SIEM systems via standard formats (CEF, JSON). Many teams use the policy engine's decision logs as a primary data source for threat detection. Integration is straightforward but requires mapping policy events to SIEM alerts.

Can we use the framework with serverless functions?

Yes, but with caveats. Serverless functions have short lifetimes and no persistent identity. The framework adapts by using invocation context and environment variables to establish identity. Policy enforcement must happen at the API gateway or through a sidecar process, which adds latency.

What is the minimum team size to adopt the framework?

We recommend at least two security engineers and one platform engineer dedicated to the framework. Smaller teams can start with a subset of the principles and expand as they grow.

Does the framework require a service mesh?

No, but a service mesh simplifies enforcement. Without one, teams need to embed policy checks in each service's code or use an API gateway for all traffic. Both approaches work, but the service mesh reduces duplication.

Summary and Next Experiments

The 3691 Framework is not a silver bullet, but it provides a structured way to engineer security for composable architectures. Its three principles—identity-first segmentation, policy-as-code, and continuous verification—address the core challenges of distributed trust. The key is to implement them incrementally, measure outcomes, and adjust.

For teams ready to experiment, we suggest three concrete steps. First, map your current service interactions and identify which ones lack service identity. Second, write one critical policy as code and test it in a staging environment. Third, set up a dashboard that shows policy compliance per service. These experiments will reveal where the framework adds the most value in your context.

Remember that security is a practice, not a product. The framework's value grows as your architecture grows. Start small, iterate, and keep the developer experience central to your approach.