How Our Community Rebuilt Authorization After an Acquisition: Expert Insights

Why an Acquisition Breaks Authorization—and Why It Matters

When two companies merge, the first thing that often breaks is authorization. I've seen it happen repeatedly: teams assume that because both companies use Role-Based Access Control (RBAC), integration will be straightforward. But the reality is far messier. Each company has its own definitions of roles, its own permission hierarchies, and its own technical debt. One team might use a flat list of permissions; the other might use a complex hierarchy with inheritance. Users who once had access to specific resources suddenly find themselves locked out or, worse, over-privileged. This isn't just an inconvenience—it's a security risk that can lead to data breaches or compliance violations.

The stakes are high. In the first few months post-acquisition, employee morale is fragile, and trust in the new leadership is still forming. If developers can't access the repositories they need, or if support staff lose access to customer data, productivity plummets. I've heard stories of teams spending weeks manually resetting permissions, causing delays in product integration and frustrating everyone involved. Beyond productivity, there's the compliance angle. Regulations like GDPR and HIPAA require strict access controls, and a messy authorization system can lead to audit failures and fines.

Real-World Scenario: The Merger of Two SaaS Platforms

Consider the case of Company A (a CRM provider) acquiring Company B (an analytics startup). Company A used a custom RBAC system with 50 roles, each with granular permissions for sales, marketing, and support. Company B used a simpler system with just three roles—admin, editor, viewer—but with resource-level restrictions that were hard-coded. After the acquisition, the combined user base of 2,000 people needed to access both platforms seamlessly. The initial attempt to merge the two systems by layering Company B's permissions on top of Company A's resulted in a cascade of errors: users in Company B could suddenly see all CRM contacts, while Company A's marketing team lost access to analytics dashboards. It took three months and a dedicated team of five engineers to untangle the mess. This is a cautionary tale that many teams can relate to.

What makes this problem particularly insidious is that it's rarely visible until it's too late. Teams often focus on data migration and feature parity, assuming authorization will just work. But authorization is like plumbing—when it fails, everything gets messy. The key is to start planning for authorization integration early, ideally before the acquisition closes. This means auditing both systems, mapping permissions, and defining a unified model that accommodates both legacy systems without breaking existing workflows. In the next section, we'll explore the frameworks that can help you do this systematically.

Core Frameworks for Rebuilding Authorization

After an acquisition, you need a framework that can handle the complexity of merging two distinct authorization models. The three most common approaches are Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Relationship-Based Access Control (ReBAC). Each has its strengths and trade-offs, and the right choice depends on your specific context. Let's break them down in a way that helps you decide which one—or which combination—works for your community.

RBAC: The Starting Point for Many Teams

RBAC is the most widely used model, and for good reason. It's simple to implement and understand: you define roles (e.g., admin, editor, viewer) and assign permissions to those roles. Users are then assigned to roles, inheriting the associated permissions. In a post-acquisition scenario, RBAC can be a lifesaver because it allows you to map roles from both companies into a unified set. For example, you might create a new role called "Cross-Platform Admin" that combines the admin permissions from both legacy systems. However, RBAC can become unwieldy when you have many roles or fine-grained permissions. I've seen teams end up with hundreds of roles, each differing by just one permission, leading to role explosion and maintenance headaches. RBAC works best when you can keep the number of roles small (say, under 20) and when permissions are relatively coarse-grained.

ABAC: Flexibility for Complex Environments

ABAC takes a different approach: instead of defining roles, you define policies based on attributes of the user, resource, and environment. For instance, a policy might say: "Allow access if user.department == 'engineering' AND resource.type == 'code' AND environment == 'production'." This model is extremely flexible and can handle complex, dynamic access scenarios. In an acquisition context, ABAC can be a powerful tool because it allows you to define policies that span both legacy systems without needing to align their role structures. However, ABAC introduces complexity in policy management. Writing and maintaining hundreds of policies can be error-prone, and debugging why access was denied often requires tracing through multiple attribute evaluations. I recommend ABAC when your authorization needs are highly context-dependent—for example, if you have regulatory requirements that depend on user location or data classification.

ReBAC: A Newer Contender

ReBAC, popularized by Google's Zanzibar paper, models authorization based on relationships between entities. For example, a user can view a document if they are a member of the team that owns the document. This model is particularly well-suited for multi-tenant applications where access is naturally hierarchical. In a post-acquisition scenario, ReBAC can help you model complex organizational structures that span both companies. For instance, you might have teams from Company A that need to collaborate with teams from Company B on specific projects, but not on others. ReBAC allows you to define these relationships declaratively, making it easier to audit and modify access patterns. The downside is that ReBAC is relatively new, and tooling is still maturing. You may need to build custom infrastructure or use specialized services like Auth0's Authorization Extension or open-source projects like OpenFGA. For most teams, a hybrid approach works best: start with RBAC for broad roles, then layer on ABAC or ReBAC for fine-grained or relationship-based rules.

Ultimately, the framework you choose should align with your team's expertise, the complexity of your permissions, and the timeline for integration. Don't over-engineer: a simple RBAC system that works is better than a sophisticated ABAC system that nobody understands. In the next section, we'll walk through the execution steps to rebuild authorization in practice.

Step-by-Step Execution: Rebuilding Authorization in Practice

Rebuilding authorization after an acquisition is a project that touches every part of the organization. It requires careful planning, cross-team collaboration, and a phased approach. Based on experiences shared by community members, here's a repeatable process that breaks down the work into manageable phases. Each phase has clear deliverables and checkpoints to ensure you're on track.

Phase 1: Audit and Map Existing Permissions

Before you can rebuild, you need to understand what you have. This means conducting a comprehensive audit of both legacy systems. For each system, document every role, every permission, and every user-to-role assignment. Tools like csv export from your identity provider, or custom scripts to query databases, can help. But don't just collect data—analyze it. Look for patterns: which permissions are most commonly assigned? Which roles are actually used? In many acquisitions, teams discover that 30% of permissions are never used, or that certain roles have accumulated permissions over time that no longer make sense. This audit is also an opportunity to clean house. Remove stale roles, consolidate duplicate permissions, and document the business rationale for each remaining permission. I recommend creating a permission matrix that maps legacy roles to proposed new roles, highlighting gaps and overlaps. This matrix will be your blueprint for the new system.

Phase 2: Design the Unified Authorization Model

With the audit complete, you can design the unified model. This is where you decide on the framework (RBAC, ABAC, or hybrid) and define the new roles and policies. Start by identifying the core user personas across both organizations. For example, you might have developers, project managers, and executives from Company A, and analysts and data scientists from Company B. Group these personas into roles that make sense for the combined organization. Then, for each role, define the minimum permissions needed to do their job—following the principle of least privilege. This is also the time to standardize naming conventions. Use consistent, descriptive names for roles and permissions. Avoid acronyms that only one team understands. Once the model is designed, socialize it with stakeholders from both sides. Hold review sessions to validate that the model meets everyone's needs. This step is crucial for buy-in; if teams feel their requirements are ignored, they will resist the new system.

Phase 3: Implement the Migration

Implementation should be incremental. Start with a pilot group—a small team that uses a representative subset of permissions. Migrate them to the new system first, and closely monitor for issues. Use this pilot to test your migration scripts, validate that permissions work correctly, and gather feedback. After the pilot succeeds, roll out to the rest of the organization in waves. Each wave should include a clear communication plan: what is changing, when, and what users need to do. Provide training sessions or documentation if the new system changes how users request or manage permissions. During migration, maintain the old systems as fallback. If something goes wrong, you can quickly revert. I've seen teams underestimate the time needed for migration. Plan for at least a month of parallel running, where both systems are active but the new one is authoritative. This allows you to catch edge cases without disrupting work.

Phase 4: Monitor and Iterate

After the migration is complete, the work isn't done. Authorization needs evolve as the organization grows and changes. Set up monitoring to track permission usage, access denials, and role assignments. Use this data to identify opportunities for simplification. For example, if you find that many users are requesting exceptions to a role, that role may need to be split or refined. Establish a regular review cadence—quarterly or bi-annually—to audit permissions and remove stale ones. This ongoing maintenance prevents the system from degrading into the same mess you inherited. In my experience, teams that treat authorization as a one-time project end up with problems six months later. Make it a living system.

Tools, Stack, and Maintenance Realities

Choosing the right tools for authorization can make or break your rebuild. The market offers everything from open-source libraries to full-fledged authorization as a service. The key is to pick tools that match your team's skills and the scale of your needs. Let's look at the most common options, their costs, and the maintenance burden they carry.

Open-Source Options: Casbin, OPA, and OpenFGA

For teams that want full control, open-source tools are attractive. Casbin is a versatile library that supports RBAC, ABAC, and even custom models. It's written in Go, but has bindings for many languages. The downside is that you need to manage the infrastructure yourself—database, scaling, and monitoring. Open Policy Agent (OPA) is another popular choice, especially for teams already using Kubernetes or microservices. OPA uses a policy language called Rego and can be deployed as a sidecar or service. It's powerful but has a steep learning curve. OpenFGA, inspired by Google's Zanzibar, is designed for ReBAC. It's still maturing but offers a promising model for relationship-based authorization. All open-source tools require ongoing maintenance: updates, security patches, and tuning. If you have a dedicated platform team, this is feasible. Otherwise, the operational overhead can be significant.

Managed Services: Auth0, Cerbos, and Permit.io

Managed services abstract away the infrastructure. Auth0's Authorization Extension provides a UI for managing roles and permissions, and integrates with their identity platform. It's easy to set up but can become expensive as your user base grows. Cerbos is a cloud-native authorization service that offers a GitOps-friendly approach: policies are defined in code and deployed via CI/CD. This makes it easy to audit and version control. Permit.io offers a visual policy editor and supports both RBAC and ABAC. It's designed for developers who want to embed authorization quickly. The trade-off with managed services is cost and vendor lock-in. You'll pay per user or per API call, and migrating away later can be painful. Evaluate your expected growth and budget carefully.

Maintenance Realities: What No One Tells You

Regardless of the tool, maintenance is a fact of life. Authorization policies drift over time as teams add new features and users change roles. I've seen organizations where 50% of permissions are unused within a year. To combat this, automate as much as possible. Use scripts to scan for unused permissions and send reports to managers. Implement just-in-time (JIT) access for high-risk permissions—users can request temporary elevation, which expires automatically. Also, establish a change management process. Any change to a role or policy should go through review and testing, just like code changes. Finally, budget for ongoing training. As your team grows, new members need to understand the authorization model. Document the model, the policies, and the decision rationales. This documentation will save you countless hours in the long run.

Growth Mechanics: Scaling Authorization as the Community Grows

Post-acquisition, the combined organization will likely grow—new hires, new projects, and new customers. Your authorization system must scale with this growth without becoming a bottleneck. The mechanics of scaling involve both technical and organizational changes. Let's explore how to position your authorization for growth, focusing on traffic handling, team ownership, and persistence in policy enforcement.

Technical Scaling: From Monolithic to Distributed

If you start with a simple RBAC system, it may work for a few hundred users. But as you approach thousands or tens of thousands, performance becomes a concern. Centralized authorization checks can become a bottleneck. To scale, consider distributing the authorization logic. For example, you can cache user permissions in a lightweight format like JWTs, so that each service can authorize requests locally without calling a central service. This is the approach used by many modern platforms. However, caching introduces the challenge of invalidation: when a user's role changes, you need to revoke their cached tokens. Short token lifetimes (e.g., 15 minutes) are a common solution. Another approach is to use a sidecar pattern, where a policy agent runs alongside each service and enforces policies based on a centralized policy store. This works well with OPA or similar tools. In either case, plan for load testing. Simulate peak usage, such as after an acquisition when all users are migrating at once. I've seen systems crash under the load of mass permission recalculations. Stress-test your authorization layer before going live.

Organizational Scaling: Who Owns Authorization?

As the community grows, you need clear ownership of the authorization system. In many organizations, authorization falls into a gap between security, platform engineering, and product teams. This leads to neglect and drift. I recommend establishing an authorization team (or at least a designated person) within the platform engineering group. This team is responsible for the infrastructure, tools, and processes. They also act as consultants for product teams that need to define new permissions. For example, when a new feature is built, the product team should work with the authorization team to define the required permissions and ensure they align with the existing model. This prevents the ad-hoc creation of roles that happen outside the governance process. Also, set up a regular forum—a monthly "authorization office hours"—where teams can ask questions and raise issues. This fosters a culture of collaboration and shared responsibility.

Persistence: Keeping the System Clean Over Time

Growth inevitably leads to complexity. Without constant attention, permissions will multiply and become inconsistent. To maintain a clean system, adopt a policy of "least privilege by default" and require justification for every new permission. Use automated tools to detect anomalies, such as a user with more permissions than 95% of their peers. Run quarterly audits and publish a report to the organization. This transparency keeps everyone accountable. Also, plan for periodic restructuring. As the organization evolves, roles may need to be merged or split. For instance, after a year, you might find that the "Developer" role has grown too broad and needs to be split into "Frontend Developer" and "Backend Developer." Embrace this evolution—it's a sign of healthy growth, not failure.

Risks, Pitfalls, and Mitigations: What Can Go Wrong

Even with the best planning, rebuilding authorization after an acquisition is fraught with risks. I've compiled a list of common mistakes based on community stories, along with practical mitigations. Knowing these pitfalls can save you weeks of pain.

Pitfall 1: Ignoring Cultural Differences in Permissioning

One of the most overlooked risks is the cultural difference in how permissions are managed. Company A might have a culture of openness, where developers have broad access to production. Company B might be highly restrictive, with every access request requiring manager approval. When these cultures collide, users from Company A may feel micromanaged, while users from Company B may feel insecure about data exposure. The mitigation is to acknowledge these differences openly. During the design phase, survey users from both sides about their comfort levels and requirements. Find a middle ground that respects both cultures. For example, you could have a default policy that is moderately restrictive but allow teams to request broader access with justification. Transparency is key—explain why certain restrictions are in place and how they protect the community.

Pitfall 2: Over-Engineering the Model

In the excitement of designing a new system, teams often try to create the perfect authorization model that covers every possible future scenario. This leads to over-engineering: complex ABAC policies, intricate relationship graphs, and dozens of roles. The result is a system that no one understands, leading to misconfiguration and errors. The mitigation is to start simple and iterate. Use RBAC as a base and add complexity only when there's a clear business need. For every new policy, ask: "Can this be handled by a role assignment?" If yes, avoid ABAC. Also, prototype the model with a small group before committing. Get feedback and simplify. Remember, a simple system that works is better than a sophisticated system that fails.

Pitfall 3: Inadequate Testing of Edge Cases

Authorization is full of edge cases: What happens when a user is in two roles? What if a resource is shared across teams? What about temporary access for contractors? Many teams test only the happy path and discover the edge cases in production, causing outages. The mitigation is to create a comprehensive test suite that covers these scenarios. Use property-based testing to generate random combinations of roles, resources, and users, and verify that the policies behave correctly. Also, simulate real-world usage patterns by replaying access logs from the legacy systems. This ensures that the new system matches the old behavior for valid access patterns. Finally, have a rollback plan. If something goes wrong, you should be able to revert to the old system within minutes.

Mini-FAQ: Common Questions About Rebuilding Authorization

Based on community discussions, here are answers to the most frequent questions that arise during an authorization rebuild.

How long does the rebuild typically take?

The timeline varies widely depending on the complexity of the legacy systems and the size of the user base. For a small team (under 500 users) with simple RBAC, the process can take 4-6 weeks. For larger organizations with complex ABAC or multiple legacy systems, expect 3-6 months. The key is to break the work into phases and not rush the pilot. A rushed migration often leads to mistakes that take longer to fix than the original plan.

Should we keep the old systems running during migration?

Yes, absolutely. Run both systems in parallel for at least a month. This allows you to compare access decisions and catch discrepancies. It also provides a safety net: if the new system has a bug, users can fall back to the old system. However, be clear that the new system is authoritative for any changes. This means that when a user's role changes, you update the new system and let the old system slowly drift out of sync. Eventually, you can decommission the old system once you're confident in the new one.

What about external users, like customers or partners?

External users add another layer of complexity. They may already have accounts with permissions in one of the legacy systems. The best approach is to treat them as a separate user pool with their own roles and policies. Don't mix internal and external roles in the same system—this creates confusion and security risks. Use a separate identity provider or a distinct namespace. Also, consider using delegation patterns: external users can be assigned roles by their internal sponsors, who are responsible for their access.

How do we handle compliance audits?

Compliance is often a driver for the rebuild. To satisfy auditors, you need to demonstrate that you have a controlled authorization process. This means keeping logs of all permission changes, having an approval workflow for high-risk permissions, and conducting regular reviews. Most managed services provide audit logs out of the box. For open-source systems, you may need to build logging yourself. Also, document the rationales for your model and any exceptions. Auditors appreciate clear documentation even more than technical perfection.

Synthesis and Next Actions: Your Roadmap to Success

Rebuilding authorization after an acquisition is one of those projects that no one wants to do, but everyone benefits from when it's done right. The key takeaways from this guide are: start early, audit thoroughly, choose a framework that matches your complexity, execute in phases, and plan for ongoing maintenance. The community stories I've shared show that success is achievable with the right approach, but it requires commitment from leadership and collaboration across teams.

Your Immediate Next Steps

1. Form a cross-team working group. Include representatives from both legacy organizations, plus security and platform engineering. This group will own the rebuild from start to finish.
2. Conduct the audit. Start with a spreadsheet or a simple database. List every role, permission, and user assignment from both systems. Identify duplicates and gaps.
3. Choose your framework and tools. Use the comparison earlier in this guide to decide. Start with RBAC unless you have a clear need for ABAC or ReBAC. Select tools that your team can support long-term.
4. Design the new model and get buy-in. Present the proposed roles and policies to stakeholders. Incorporate feedback and finalize the design.
5. Execute the migration in phases. Start with a pilot, then roll out in waves. Maintain the old system as a fallback.
6. Set up monitoring and a review cadence. Automate where possible, and schedule quarterly audits to keep the system clean.

Remember, the goal is not perfection—it's progress. Your authorization system will never be perfect, but with a solid foundation and a habit of regular maintenance, it can serve your community well for years to come.