What is Birth Right Access

Birthright Access refers to the baseline or default permissions and access to resources granted to all new users (likely employees) the moment they join an organization, not taking into account their specific role, department, or job functions. It is like being handed a "welcome kit" of digital access just by being an employee. The permissions typically apply broadly and are intended for initial, rough access to things like email, intranet, and human resources that the organization assumes are essential for everyone and the vast majority of users.

While it seems to aid in quick onboarding, Birthright Access is the extreme opposite of modern cybersecurity principles such as Least Privilege Access (LPA) and Zero Trust. Instead of only assigning the essential permissions to do the job for a specific role, birthright access does not discriminate; it assumes every new hire is granted the average set of permissions needed just to make sure that they can do their job. In its "one size fits all" approach, birthright access typically leads to users having more access than they either need or were even aware they had, leading to insecure defaults.

Why is Birthright Access Commonly Used ?

The birthright access model has proliferated as an accepted practice when organizations feel an immediate need for to give productivity along with pushing IT departments to simplify the process of onboarding new hires.

• Urgent Onboarding: The most prevalent justification for Birthright Access is to get new hire workers productive as quickly as possible and to offer immediate access to mandatory "tools," such as email, management systems, or subscribed intranet systems. Therefore, permissions associated with immediate access/usage are granted with little consideration of their role.

• Administrative Efficiency: Additionally, the model requires less administrative work for IT and HR functions, as it automates a baseline of access to individual users that is relatively the same (defined by a standard).

Despite all these purported benefits, there are serious security and compliance risks that often go unaddressed:

• Least Privilege Violations: This is the single most important issue. Because Birthright Access grants permissions far beyond the needs of the initial tasks the user may have undertaken, it is true, by definition, that Birthright Access violates LPA from the outset.

• Increased Attack Surface: Every superfluous permission granted is an opportunity for compromise. Once an attacker has breached an account with broad birthright access, the attacker has immediate and uncharted access to more systems and data than they would have otherwise, had there been step functions to their access.

• Heightened Insider Threat: Just as with external threats, insiders with excessive birthright permissions pose a heightened risk, whether malicious (insider threat) or accidental (inadvertently exposing or abusing data not related to their role).

• Compliance Nightmares: Compliance regulations such as GDPR, HIPAA, PCI DSS, SOX, FedRAMP, SOC 2 are strict about what is known about sensitive data. Broad Birthright Access can pose severe challenges in demonstrating to regulatory authorities, after the fact of an audit, that only authorized individuals had access to regulated information, and violating a compliance regulation could trigger fines or other negative consequences for the organization.

• Audit Complexity: Broad Birthright Access permissions can create a compliance nightmare for auditors performing audits on organizations. Tracking broad birthright permissions across an entire organization, and further justifying that privilege, is often incredibly complicated for an auditor to demonstrate they control.

• "Access Bloat," or Dormant Permissions: When more than one user has "free access" for any reason, organizational rules will lead other users to retain their birthright access while adding permissions for other specific roles. This is called "access bloat"; it is an extension of a spreadsheet but nonetheless today it has just created confusion across which behavior is appropriate and has stopped organizations from moving to less permissive (or at least tight) configuration.

• Zero Trust Standard: Zero Trust requires an assessment of every access request to be verified. Birthright Access in effect assumes the least privilege of trust in the first place for the initial access request, and that makes it difficult to demonstrate verification subsequently.

Typical Components of Birthright Access:

Typical components of Birthright Access may include:

• Email Access: Typical corporate email account access.

• Basic Network Access: Basic corporate network access, often including internet access.

• Intranet Access: Access to internal published company content, websites, and announcements.

• HR System Access: Limited access to view personal HR source records (e.g., payroll, benefits).

• Common Shared Drives: Read-only (or sometimes read/write) access to general corporate shared drives that only contain non-sensitive information.

• Standard Productivity Tools Access: Access to standard suite applications (e.g., Microsoft 365, Google Workspace).

Moving beyond Birthright Access: Some Good Practices:

While accomplishing complete removal may not be achievable for some organizations, all organizations should pursue a reduction in the scope of and risk associated with Birthright Access.

• Strictly Define Baseline: If an organization cannot eliminate Birthright Access, then define the minimum number of permissions necessary for any employee to perform functions, for example, the narrowest grouping of permissions.

• Just-in-Time (JIT) Access: Provide access as necessary by role, for only the case of need, for predetermined limited duration, but then automatically revoke access once the case is over. This is the opposite of Birthright Access.

• Utilize Fine-Grained Access Control: Many organizations provide broad folder access; instead, organizations should consider access at the point of file, row, function, and so on, and consider the context and attributes of the user.

• Automate Access Reviews and Certifications: Any organization should instill regular access reviews (e.g., quarterly or bi-annually), where they examine and certify all current access rights to seek out and eliminate permissions that are stale or excessive in scope, especially for permissions that are just left over from Birthright Access.

• Role-Based Access Control (RBAC) with Granularity: Create well-defined roles that relate reasonably to actual job functions. When additional permissions are granted, they are granted through specific approved roles, not as a part of some default "birthright" offer.

• Strong On-boarding Off-boarding Workflows: Make sure access provisioning for new hires relates to their actual role from day one. Once employees leave the organization, ensure all access is terminated immediately, including birthright elements.

• Zero Trust Principles: Leverage a "never trust, always verify" strategy. Verify all access, including the initial baseline access, each and every time based on context.

How ReShield Can Help Address the Risks of Birthright Access:

ReShield's identity security platform has the full-featured tools required to move away from the risky paradigm of Birthright Access to a more secure, modern access management practice.

• Granular Role-Based Access Control (RBAC): ReShield's robust Identity Governance and Administration (IGA) features allow organizations to develop highly granular roles and associated permissions by starting out granular. Access for new employees can be aligned with initial job functions instead of just a default "birthright" package.

• Just-in-Time (JIT) Access: With ReShield's Privileged Access Management (PAM) features and JIT Access features, organizations can assign temporary elevated permissions only for the activity they require, and based on a limited duration. This provides limited standing access so that, if they have any initial baseline access, it is limited. Then an employee would have to request elevated permissions only when required, and the elevated permissions would have to be approved and tied to a task.

• Automated Access Reviews and Certifications: ReShield automates access review and certification for all access rights, making it easy to certify that excessive or dormant permissions are identified and revoked or rescinded as needed. ReShield also can enforce LPA (Least Privilege Access) continuously.

• Policy-Driven Access Control: ReShield's platform supports the creation and enforcement of policy-based access permissions that dynamically model the context of access. Even the most basic access could be verified by user attributes, device posture, or time-based criteria, totally aligning with a Zero Trust security model.

• Audit Trail: ReShield provides direct audit logging, immutably preserving all access requests and approvals. This eliminates the questions of "who did what" - with clear visibility into who has what access, it is also great for compliance purposes. ReShield records granular access, which is a lot better than the default birthright access!

By adopting ReShield as your Identity Security platform, you can eliminate the underlying risks of Birthright Access and create a much more secure, compliant, and efficient Identity and Access Management framework, all while ensuring your employees maintain the principles of LPA and Zero Trust.