How Our Community Helped One Member Rebuild Authorization After a Merger

This overview reflects widely shared professional practices as of May 2026; verify critical details against current official guidance where applicable.

When Mergers Break Authorization: The Hidden Crisis

Corporate mergers are often celebrated as strategic growth moves, but for the IT and security teams left to untangle the aftermath, they can feel like a storm of broken systems. One of the most disruptive yet overlooked challenges is authorization—the set of rules determining who can access what. When two companies combine, their identity and access management (IAM) systems rarely align. One may use Active Directory, another Okta; one has fine-grained role-based access control (RBAC), the other relies on ad-hoc permissions. The result? Employees from the acquired company suddenly lose access to critical tools, while others inherit permissions they should never have. This was the exact situation faced by a member of our community—let's call him Alex.

Alex's Story: A Week of Lockouts and Confusion

Alex was a senior systems engineer at a mid-sized SaaS company that was acquired by a larger enterprise. Within days of the merger announcement, his access to production databases, CI/CD pipelines, and even email was intermittently blocked. His team was paralyzed. Requests for access had to go through a new, unfamiliar ticketing system, and approvals took days. Worse, some of his colleagues from the acquiring company suddenly had view access to sensitive customer data they didn't need. Alex felt the pain of a system that was never designed for this scale of integration.

The Community Steps In

Frustrated, Alex posted on our community forum, describing his situation and asking for advice. Within hours, several members with merger experience responded. One suggested he start by mapping the current authorization state before proposing any changes. Another pointed him to a framework for comparing RBAC versus attribute-based access control (ABAC). A third shared a script for auditing Active Directory group memberships. This collective knowledge became the foundation of his rebuild. The community didn't just offer sympathy—they provided actionable, battle-tested steps that had worked in similar scenarios.

The core lesson Alex learned, and one that applies broadly, is that authorization after a merger requires a deliberate, phased approach. You cannot simply merge two IAM systems overnight. Without a structured plan, you risk security vulnerabilities, productivity loss, and employee frustration. In the sections that follow, we'll break down the frameworks, tools, and processes that helped Alex—and can help you—navigate this complex transition.

Core Frameworks: RBAC, ABAC, and Hybrid Models

To understand how Alex rebuilt authorization, we first need to explore the fundamental frameworks that govern access control. The two most common models are Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC), each with its own strengths and trade-offs. A third option, the hybrid model, combines elements of both. Choosing the right framework—or a combination—is critical because it determines how permissions are assigned, audited, and maintained post-merger.

RBAC: Simplicity and Structure

RBAC assigns permissions based on predefined roles, such as 'Developer', 'Admin', or 'Viewer'. It is straightforward to implement and audit, making it a favorite for organizations with clear job functions. In a merger context, RBAC can help by mapping roles from both companies to a unified set. However, it becomes rigid when employees need granular access that doesn't fit a role—common in merged organizations where people wear multiple hats. Alex found that his original company used RBAC with 15 roles, while the acquiring company had over 100 roles, many overlapping. The community advised him to consolidate roles by function rather than by legacy company, reducing to 40 roles that covered 90% of access needs.

ABAC: Flexibility at a Cost

ABAC uses attributes (user department, location, time of day, resource sensitivity) to determine access dynamically. It offers fine-grained control and adapts well to complex, cross-functional teams. In a merger, ABAC can handle scenarios like 'Only allow access to customer data if the user is in the Sales department AND the account was created before the merger date'. However, ABAC requires a robust attribute management system and can become difficult to debug when policies conflict. Alex initially considered ABAC for its flexibility, but the community warned him that implementing it from scratch during a merger would be too disruptive. Instead, they recommended a phased approach: start with RBAC, then layer in ABAC later if needed.

Hybrid Model: The Pragmatic Choice

Many organizations, including Alex's, find that a hybrid model offers the best balance. In this approach, core access is managed via RBAC roles, while exceptions and fine-grained controls are handled through ABAC policies. For example, a 'Developer' role might grant access to all development environments, but an ABAC policy could restrict access to production data based on a 'project_code' attribute. The community helped Alex design a hybrid model that used RBAC for 80% of access decisions and ABAC for the remaining 20%. This reduced the initial complexity while allowing room for future customization.

The choice of framework directly impacts the rebuild timeline. RBAC-only implementations can be fast to deploy but may require frequent role modifications. ABAC-only systems are more adaptable but demand a mature data governance structure. For most post-merger scenarios, the hybrid model is recommended as a pragmatic middle ground. Alex's experience underscores the importance of not over-engineering the solution—start simple, then iterate.

Step-by-Step Execution: From Audit to Rollout

With a framework selected, the next challenge is execution. Alex's community-guided plan consisted of five phases: audit, design, test, rollout, and monitor. Each phase had specific deliverables and checkpoints to ensure nothing was overlooked. Below, we detail each step with the practical advice that helped Alex succeed.

Phase 1: Comprehensive Access Audit

Before changing anything, Alex needed to know who had access to what. The community recommended using tools like Varonis or manual scripts to export all permissions from both companies' IAM systems. He created a spreadsheet mapping user IDs, roles, group memberships, and last access dates. This revealed over 200 orphaned accounts—former employees or contractors still active in the system. The audit also highlighted over-provisioned accounts, where 30% of users had more permissions than their job required. Alex presented this data to leadership, which helped secure buy-in for the rebuild.

Phase 2: Design the New Authorization Model

Using the audit results, Alex designed a unified model. He started by defining 40 roles based on job functions rather than legacy company structures. For each role, he listed required permissions and documented any exceptions. The community shared a template for role definition that included fields for role name, description, assigned resources, and approval chain. Alex also created an attribute dictionary for the ABAC layer, listing possible values for department, location, and project code. This design phase took two weeks of collaboration with department heads, but it prevented future conflicts.

Phase 3: Testing in a Sandbox Environment

Before rolling out to production, Alex set up a sandbox environment that mirrored both companies' systems. He used a tool like JumpCloud to simulate the new authorization model with a subset of users. The community advised him to test three scenarios: normal user access, manager access, and emergency break-glass access. During testing, they discovered that the role 'Support Engineer' lacked permissions to reset passwords—a critical gap. Alex fixed this before deployment. Testing also revealed that some ABAC policies incorrectly blocked access for remote workers, which he adjusted.

Phase 4: Phased Rollout

Alex rolled out the new model in waves, starting with a pilot group of 50 users from the acquired company. The community emphasized communication: he sent emails explaining what would change, when, and how to report issues. After two days of monitoring, only three minor issues were reported, all resolved within hours. He then expanded to the entire acquired company (300 users), then to the acquiring company's teams that interacted with them. The full rollout took three weeks, with a rollback plan in place if critical failures occurred.

Phase 5: Continuous Monitoring

Post-rollout, Alex set up alerts for any access denied errors and scheduled monthly reviews of role assignments. The community recommended using a tool like Access Monitor to track permission changes. Over the next quarter, Alex reduced orphan accounts by 90% and cut access request resolution time from days to hours. The rebuild was considered a success, and Alex credited the community for providing the structured approach he couldn't have developed alone.

Tools, Costs, and Maintenance Realities

Choosing the right tools and understanding the economics of authorization management is essential for long-term success. Alex evaluated several IAM platforms before settling on a combination that fit his budget and technical environment. Below, we compare three common approaches: on-premises identity management, cloud-based IAM, and a hybrid solution.

Option 1: On-Premises Identity Management (e.g., Microsoft Identity Manager)

This approach involves running IAM software on your own servers. It offers full control over data and customization, making it suitable for organizations with strict compliance requirements. However, it requires dedicated IT staff for maintenance, updates, and scaling. Alex's acquiring company had an on-premises system, but it was struggling with performance after the merger doubled its user base. The community estimated that scaling it would cost $50,000–$100,000 in hardware and labor, plus ongoing costs for a system administrator. For a post-merger scenario, on-premises can be slow to adapt if roles change frequently.

Option 2: Cloud-Based IAM (e.g., Okta, Azure AD)

Cloud IAM services offer rapid deployment, automatic updates, and built-in integration with thousands of apps. They are subscription-based (typically $2–$15 per user per month), which can be more predictable than on-premises costs. Alex's original company used Okta, and the community praised its ease of use for mergers because it can federate with multiple directories. However, cloud IAM may have limitations on custom policies, and data residency can be a concern for some industries. Over a three-year period, the total cost of ownership for 2,000 users is roughly $144,000–$360,000, depending on the plan.

Option 3: Hybrid IAM (e.g., leveraging both on-premises and cloud)

Many large enterprises, including the one Alex worked for, adopt a hybrid model. They keep sensitive systems on-premises while using cloud IAM for SaaS applications. This provides flexibility but increases complexity in managing two systems. The community advised Alex to use a cloud-based directory as the source of truth for user identities, then sync it to the on-premises system for legacy apps. This approach cost about $30,000–$60,000 in initial setup and $15,000 annually for cloud subscriptions. It required a part-time IAM engineer to maintain the sync scripts. The trade-off is higher operational overhead, but it can accommodate diverse requirements without forcing a full migration.

Maintenance Realities

Regardless of the toolset, authorization management is not a one-time project. Alex learned that regular access reviews, certifications, and policy updates are necessary. The community recommended quarterly access recertifications where managers confirm their team's permissions. They also suggested implementing a 'zero standing privileges' approach for critical systems, where users request temporary elevated access via a tool like CyberArk. Maintenance costs can add 20–30% to the initial investment annually. Alex budgeted for a part-time IAM coordinator to handle these tasks, which proved essential for sustaining the new system.

Ultimately, the choice depends on your organization's size, budget, and compliance needs. For most post-merger scenarios, cloud-based or hybrid IAM offers the best balance of speed and flexibility. Alex's hybrid solution allowed him to integrate quickly while maintaining control over legacy systems.

Growth Mechanics: Scaling Access Without Breaking Trust

Once the new authorization system is in place, the next challenge is scaling it as the merged organization grows. New hires, departmental reorganizations, and evolving projects all require updates to roles and policies. Without a scalable approach, the system can become bloated with excessive permissions or outdated rules. Alex's community shared strategies for managing growth while maintaining security and efficiency.

Automating Role Assignments with Provisioning Rules

One key growth mechanic is automating role assignments based on employee attributes. For example, when a new developer joins, a rule can automatically assign them the 'Developer' role and add them to relevant groups. Alex implemented this using his cloud IAM's lifecycle management features. The community cautioned against full automation without oversight—they recommended a 'just-in-time' model where new users get a minimal default role, and managers approve additional access within 24 hours. This reduced the risk of over-provisioning while keeping onboarding fast.

Periodic Access Reviews and Role Cleanup

As the organization grows, roles can accumulate permissions that are no longer needed. Alex set up quarterly access reviews using a tool like SailPoint, which sends managers a list of their team's permissions and asks them to confirm or revoke. The first review uncovered that 15% of users had permissions tied to projects that had ended. The community emphasized that reviews should be mandatory and tied to performance metrics to ensure compliance. They also recommended using 'role mining' techniques to identify common permission patterns and suggest new roles that could simplify management.

Handling Cross-Functional Teams and Temporary Access

In a merged company, cross-functional teams are common. A marketing analyst might need temporary access to a development database to run a campaign report. Alex used time-bound ABAC policies for these scenarios, granting access for a specific duration (e.g., 30 days). The community suggested creating a 'temporary access' role that combines minimal permissions and auto-expires. This avoids permanent changes to the user's primary role. Alex also set up a self-service portal where users could request temporary access, with approvals routed to the resource owner. This reduced the burden on IT and empowered teams to move quickly.

Monitoring for Permission Creep

Permission creep occurs when users accumulate access over time, often through role changes or project assignments. Alex monitored this by running monthly reports comparing current permissions to baseline roles. The community shared a script that flagged any user whose permissions exceeded 120% of their role's baseline. Those users were flagged for review. Over six months, Alex reduced permission creep by 40%. He also implemented a 'least privilege' policy where default roles grant the minimum access needed, and any additional access must be justified and approved.

Scaling authorization is not just about adding more users—it's about maintaining the integrity of the access model. By automating where possible, reviewing regularly, and providing self-service options, Alex built a system that could grow with the company without compromising security. The community's advice on these growth mechanics was instrumental in ensuring the rebuild had long-term staying power.

Risks, Pitfalls, and How to Avoid Them

Even with a solid plan, rebuilding authorization after a merger is fraught with risks. Alex encountered several pitfalls, and the community helped him navigate them. Here, we highlight the most common mistakes and how to mitigate them.

Orphaned Accounts and Shadow IT

Orphaned accounts—user accounts that remain active after an employee leaves—are a major security risk. During the audit, Alex found 200 such accounts from both companies. The community advised immediate deactivation of all accounts not tied to active employees. They also warned about shadow IT: employees creating their own access, like sharing passwords or using unsanctioned apps. To counter this, Alex implemented a policy requiring all access to go through the official IAM system, and he educated staff on the risks of shadow IT via a company-wide email.

Over-Provisioning and Role Explosion

In an effort to avoid access denials, some administrators grant excessive permissions. This leads to role explosion—creating too many roles to cover every scenario, which becomes unmanageable. Alex's initial design had 120 roles, but the community helped him consolidate to 40 by grouping similar functions. They suggested a 'role gardening' approach: start with broad roles and create exceptions only when necessary. Over-provisioning can also be mitigated by using ABAC policies for specific access instead of creating new roles.

Resistance to Change from Employees

Employees from the acquired company may feel that the new authorization system is a loss of autonomy or trust. Alex faced pushback from a senior engineer who had always had full access to all systems. The community advised Alex to communicate the benefits: better security, fewer disruptions, and easier onboarding. He held town hall meetings to explain the changes and address concerns. He also created a 'power user' role for senior engineers that granted broader access but still followed the new framework. This compromise reduced resistance significantly.

Integration Failures and System Downtime

When integrating two IAM systems, there is a risk of synchronization failures or downtime. During Alex's rollout, a glitch in the sync script caused some users to lose access to email for two hours. The community had stressed the importance of a rollback plan: Alex had snapshots of the previous state and could revert within 30 minutes. He also set up a communication channel (Slack) where users could report issues immediately. For future integrations, the community recommended using a 'staging environment' that mirrors production, and running the rollout during off-hours.

Compliance and Audit Trail Gaps

Merged organizations often face regulatory scrutiny, especially if they handle financial or health data. Alex's company had to comply with SOC 2 and GDPR. The community pointed out that the new authorization system must maintain a complete audit trail of who accessed what and when. Alex configured logging for all access decisions and stored logs for at least one year. He also set up quarterly compliance reports that were reviewed by the legal team. Failure to do so could result in fines or loss of business.

By anticipating these pitfalls and having mitigation strategies in place, Alex was able to navigate the merger with minimal disruption. The community's collective experience was invaluable in identifying risks that a single person might have missed.

Frequently Asked Questions: Authorization After a Merger

Based on the most common questions from our community, we've compiled a FAQ addressing the top concerns about rebuilding authorization post-merger.

Q1: How long does a typical authorization rebuild take? A: It depends on the size of the organization and complexity of existing systems. For a company of 500–1000 users, the audit and design phase can take 3–4 weeks, testing another 2 weeks, and rollout 2–4 weeks. Alex's project took about 8 weeks total. The community suggests adding a buffer of 20% for unexpected delays.

Q2: Should we merge both IAM systems or choose one? A: In most cases, choosing one IAM platform as the authoritative source is simpler than maintaining two. However, if both systems have critical legacy apps that cannot migrate, a hybrid approach with synchronization may be necessary. The community recommends evaluating the cost of migration versus the cost of maintaining two systems. Often, migrating to the acquiring company's platform is more efficient.

Q3: What is the biggest mistake to avoid? A: Skipping the audit phase. Without a full picture of current permissions, you risk missing orphaned accounts or over-provisioned users. The community emphasizes that you cannot fix what you don't measure. Another common mistake is not involving stakeholders from both companies early in the design process.

Q4: How do we handle legacy systems that don't support modern IAM? A: Legacy systems can be wrapped with a proxy that enforces authorization policies. Tools like Azure AD Application Proxy or AWS SSO can front-end older apps. Alternatively, you can use a privileged access management (PAM) solution to control access directly. The community suggests prioritizing which legacy systems are critical and addressing them one at a time.

Q5: What if we have to maintain compliance during the transition? A: Ensure that the new system meets compliance requirements (e.g., audit trails, access controls) from day one. Run the new system in parallel with the old one for a period, with the new system logging all decisions. The community recommends engaging your compliance officer early and documenting the transition plan to show regulators.

Q6: How do we get management buy-in for the rebuild? A: Present the audit findings—especially the number of orphan accounts and over-provisioned users—as a security risk. Quantify potential impact: for example, the cost of a data breach from an orphaned account can be millions. Alex used a simple risk matrix to show that the rebuild had a high positive ROI. The community also suggests tying the project to business continuity, as access disruptions directly affect productivity.

Q7: What ongoing maintenance is required after the rebuild? A: Regular access reviews (quarterly), role updates (as job functions change), and monitoring for permission creep. Also, keep an eye on new applications being added—each new app should go through an IAM review. The community recommends assigning an IAM owner or team to handle these tasks.

These answers reflect the collective wisdom of practitioners who have been through similar transitions. For specific concerns, always consult your security team or an external IAM consultant.

Synthesis: Key Takeaways and Your Next Steps

Rebuilding authorization after a merger is a complex but manageable undertaking. Alex's story demonstrates that with a structured approach and the support of a knowledgeable community, even a daunting task can be broken down into achievable phases. The core lessons are clear: start with a thorough audit, choose a flexible framework (hybrid RBAC/ABAC is often best), test thoroughly, roll out in phases, and plan for ongoing maintenance. Equally important is the human element—communicate clearly with employees, involve stakeholders, and be prepared to learn from mistakes.

Your next steps should begin with an honest assessment of your current state. If you're facing a merger or have recently completed one, we encourage you to perform an access audit using the tools and techniques outlined here. Identify orphaned accounts, map permissions, and document current roles. Then, design a target model that aligns with your business needs and compliance requirements. Don't rush the design phase—it's the foundation of a stable system. Finally, engage your community, whether it's an internal team or an external forum like ours, to get feedback and avoid common pitfalls.

Remember that authorization is not a static problem. As your organization evolves, so must your access controls. Schedule regular reviews and stay informed about new IAM technologies that could simplify management. The effort you invest today will pay off in reduced security incidents, faster onboarding, and happier employees. If you have questions or want to share your own experience, our community is here to help. We've seen that when people come together to solve problems, the solutions are always stronger.