Access control is either the foundation everything else in your security stack builds on — or the gap everything falls through. Here's how it works, what the models actually mean, and what good implementation looks like at mid-market scale.
Access control is the system that determines who can access what in your organization. That's it. Everything else—RBAC, ABAC, least privilege, zero trust, conditional access—is implementation details, variations, or marketing terminology wrapped around this basic function.
When someone tries to access a file, application, database, or system, access control answers two questions:
- Authentication: Is this person who they claim to be?
- Authorization: Should this person have access to this resource?
If both answers are yes, access is granted. If either is no, access is denied.
This sounds simple. In practice, it's one of the most complex problems in IT. Because "who" isn't just 500 individual employees. "What" isn't just a few applications. And "should this person have access" involves job roles, departments, compliance requirements, security policies, device types, locations, times, risk levels, and dozens of other factors.
Here's what access control actually is, why it matters, how it's implemented, what the different approaches mean, and what you actually need to know to make good decisions for your organization.
In this article:
- Why Access Control Matters
- The Two Parts: Authentication and Authorization
- Access Control Models Explained
- How Access Control Works in Practice
- Core Principles That Guide Access Control
- Common Implementation Approaches
- What Good Access Control Looks Like
Why Access Control Matters
Without access control, everyone can access everything. The intern can access the CEO's email. Contractors can access customer databases. Former employees retain access to production systems. Attackers with any set of credentials have full access to your environment.
This creates three problems:
Problem 1: Security Risk
Scenario: Attacker phishes credentials from junior marketing coordinator. In environment without access control, those credentials grant access to everything—production databases, financial systems, customer data, HR records.
One compromised account = complete environment compromise.
With access control: Marketing coordinator credentials grant access to marketing tools only. Attacker gets HubSpot access, not production database access. Breach is contained, not catastrophic.
Problem 2: Compliance Failure
SOC 2, ISO 27001, HIPAA, PCI-DSS, and most other compliance frameworks require demonstrating who has access to what and why.
Auditor asks: "Who has access to customer credit card data?"
Without access control: "Everyone who has login credentials to our systems could potentially access it."
Compliance status: Failed.
With access control: "Only these 5 people in the billing team, assigned through role-based access control, reviewed quarterly."
Compliance status: Passed.
Problem 3: Operational Chaos
Without access control, provisioning new employees means granting access to everything because you don't have structure for determining what they should access.
Deprovisioning means trying to remember every system the employee might have accessed and manually removing access from each one.
Access reviews are impossible because you can't tell who should have access to what or why.
The overhead of managing access manually becomes overwhelming at even 50 employees.
The Two Parts: Authentication and Authorization
Access control has two distinct components that are often confused:
Authentication: Proving Identity
Question answered: Is this person who they claim to be?
How it works:
- User provides credentials (username + password)
- System verifies credentials match stored values
- Optional: Additional factors (MFA - something you have, something you are)
Authentication methods:
- Password (something you know)
- MFA app/SMS code (something you have)
- Biometric (something you are)
- Certificate (cryptographic proof)
- Hardware token (physical device)
Important: Authentication only proves identity. It doesn't determine what that identity should have access to.
Example: Your password proves you're Sarah Chen, software engineer. Doesn't prove Sarah Chen should have access to HR systems.
Authorization: Granting Access
Question answered: Should this authenticated identity have access to this resource?
How it works:
- User requests access to resource (application, file, database)
- System checks authorization rules
- Rules determine if this user should have access
- Access granted or denied based on rules
Authorization approaches:
- User has been explicitly granted access to this resource
- User is in a group that has access to this resource
- User has a role that includes access to this resource
- User's attributes (department, title, clearance) match resource requirements
Important: Authorization is where most complexity lives. Authentication is relatively straightforward (prove who you are). Authorization is complicated (determine what you should access based on who you are, what you're accessing, and context).
Why the Distinction Matters
Authentication without authorization: Everyone can prove who they are, but there's no system determining what they should access. Everyone ends up with access to everything.
Authorization without authentication: System knows who should access what, but can't verify people are who they claim to be. Attackers impersonate legitimate users.
Both required: Authentication proves identity. Authorization determines what that identity can access.
Access Control Models Explained
Different organizations implement authorization differently. Here are the main models:
Discretionary Access Control (DAC)
How it works: Resource owner decides who can access the resource. If you create a file, you decide who else can access it.
Example: You create Google Doc. You decide to share with Sarah (edit access) and John (view access). You're the discretionary authority—you control access.
Where you see this:
- File systems (Windows, Mac, Linux permissions)
- Cloud storage (Google Drive, Dropbox)
- Collaboration tools
Advantages:
- Flexible—resource owners make decisions
- Easy to understand
- Works well for small teams and collaboration
Disadvantages:
- Doesn't scale—who owns shared resources?
- Inconsistent—every owner makes different decisions
- Hard to audit—no central control
- Permissions spread and accumulate over time
When to use: Small teams (5-20 people) collaborating on documents/files. Not appropriate for enterprise application access or sensitive data.
Mandatory Access Control (MAC)
How it works: Central authority assigns classification levels to resources and clearance levels to users. Access granted only if user clearance meets resource classification.
Example: Document classified as "Top Secret." User has "Secret" clearance. Access denied—clearance insufficient.
Where you see this:
- Military and government systems
- Highly regulated industries
- Classified information handling
Classification levels (typical):
- Public / Unclassified
- Internal / Confidential
- Secret
- Top Secret
Advantages:
- Very secure—central control
- Clear rules
- Audit trail
Disadvantages:
- Rigid—hard to make exceptions
- Administrative overhead—classifying everything
- Rarely needed outside government/military
When to use: Organizations with legal requirements for classified information handling. Most commercial organizations don't need MAC.
Role-Based Access Control (RBAC)
How it works: Define roles (groups of permissions). Assign users to roles. Users get permissions from their roles.
Example: Role: "Software Engineer" Permissions: GitHub, Jira, AWS, Figma, development tools
Sarah is assigned "Software Engineer" role. Sarah gets all permissions associated with that role.
Where you see this:
- Most enterprise applications
- Identity providers (Azure AD, Okta)
- SaaS platforms
Advantages:
- Scales well—manage roles, not individual permissions
- Clear—roles map to job functions
- Auditable—can see who has which roles
- Easier than managing individual permissions
Disadvantages:
- Role explosion—end up with 200 roles when 20 would work
- Static—roles don't adapt to context
- Can't capture complex logic
- Tends to over-permission (role includes access someone doesn't need)
When to use: Pretty much every organization over 50 employees. RBAC is the standard approach for most business applications.
Group-Based Access Control (GBAC)
How it works: Create groups representing departments, teams, or functions. Assign users to groups. Grant access to groups, not individuals.
Example: Group: "Engineering" Members: All engineers Access: All engineering tools
Group: "Finance" Members: All finance team members Access: Financial systems
Important distinction: GBAC is really RBAC implemented through IdP groups. Groups in Azure AD, Okta, or Google Workspace are how you implement roles. The group is the role.
Where you see this:
- Identity providers (Azure AD, Okta, Google Workspace)
- Most SaaS application access control
Advantages:
- Built into IdP—no additional system needed
- Easy to understand
- Manageable at mid-market scale
- Automated (dynamic groups based on HR attributes)
Disadvantages:
- Same as RBAC (group sprawl, static assignments, over-permissioning)
- Requires good group structure
- Can become chaotic if poorly managed
When to use: Standard approach for most mid-market companies (100-1,000 employees). Foundation for access control.
Attribute-Based Access Control (ABAC)
How it works: Access decisions based on attributes—user attributes (department, title, clearance), resource attributes (classification, sensitivity, owner), environmental attributes (time, location, device).
Example: Policy: "Allow access to customer database IF:
- User.Department = 'Customer Success' AND
- User.EmploymentType = 'Employee' AND
- Time = Business Hours AND
- Device.Compliance = True AND
- Location = 'US'"
Dynamic access based on multiple attributes, not static role assignment.
Where you see this:
- Advanced IdP features (Azure AD Conditional Access)
- Cloud platforms (AWS IAM policies)
- Applications with fine-grained permissions
Advantages:
- Very flexible—can model complex policies
- Dynamic—adapts to context automatically
- Granular—different rules for different scenarios
- Reduces over-permissioning
Disadvantages:
- Complex to implement
- Hard to audit (policies can be opaque)
- Requires mature attribute management
- Can be over-engineered for simple needs
When to use: Organizations with complex authorization requirements, strong compliance needs, or mature identity infrastructure. Don't start here—evolve to ABAC after mastering RBAC.
Context-Based / Conditional Access
How it works: Layer on top of RBAC/GBAC that adds dynamic context—time, location, device, risk level—to access decisions.
Example: Base access: Engineer can access production AWS (from RBAC/role).
Context adds:
- IF accessing from new country: Require MFA
- IF accessing from unmanaged device: Deny admin operations
- IF accessing outside business hours: Require additional approval
Where you see this:
- Azure AD Conditional Access
- Okta Adaptive MFA
- Google Context-Aware Access
Advantages:
- Adds security without changing base access model
- Catches compromised credentials
- Adapts to risk level
- Balances security and usability
Disadvantages:
- Requires understanding access patterns first
- Can create user experience friction
- Adds complexity to troubleshooting
- Needs testing to avoid breaking workflows
When to use: After establishing clean RBAC/GBAC foundation. Layer context on top of groups, don't replace groups with context.
How Access Control Works in Practice
Theoretical models are one thing. Here's what access control actually looks like in a mid-market company:
The Stack
Identity Provider (IdP):
- Azure AD, Okta, or Google Workspace
- Central user directory
- Handles authentication (SSO, MFA)
- Manages groups/roles
- Provisions access to applications
Applications:
- SaaS apps (Salesforce, GitHub, etc.)
- On-premise apps
- Cloud infrastructure (AWS, Azure, GCP)
- Each has own permission model
Identity Governance (optional):
- Access reviews
- Provisioning automation
- Compliance reporting
- Usage analytics
The Flow
1. New hire joins:
HR creates employee record:
- Name: Sarah Chen
- Department: Engineering
- Job Title: Software Engineer
- Start Date: Nov 1
2. IdP syncs from HR:
Azure AD/Okta/Google pulls HR data:
- User account created
- Attributes populated (department, title, type)
3. Groups populate automatically:
Dynamic group rules trigger:
- Department = "Engineering" → Add to Dept-Engineering group
- JobTitle contains "Engineer" → Add to Role-Developer group
- EmploymentType = "Employee" → Add to Employees-FullTime group
4. Applications provision from groups:
Applications assigned to groups provision automatically:
- Dept-Engineering has GitHub → Sarah gets GitHub
- Role-Developer has AWS → Sarah gets AWS dev access
- Employees-FullTime has Slack → Sarah gets Slack
5. Sarah logs in:
Authentication:
- Sarah enters username + password
- MFA prompt (authenticator app)
- Authentication successful
Authorization:
- Sarah tries to access GitHub
- IdP checks: Is Sarah in a group with GitHub access?
- Yes (Dept-Engineering group has GitHub)
- GitHub access granted
What Makes This Work
Single source of truth: HR system is authoritative for department, title, employment status.
Automation: Groups populate from HR attributes automatically. No manual tickets.
Least privilege: Sarah only gets access appropriate for her role, not everything.
Auditability: Can see which groups Sarah is in, which groups have which access, why Sarah has what she has.
Scalability: Same process for hire #1 and hire #500. Automation doesn't break at scale.
Core Principles That Guide Access Control
Good access control follows these principles:
1. Least Privilege
Principle: Users should have minimum access necessary to do their jobs. Nothing more.
Why it matters: Every unnecessary permission is potential attack surface. Compromised account can only damage what it has access to.
In practice:
- New hire gets baseline access + role-specific access
- Not baseline + role-specific + "everything just in case"
- Remove access when role changes
- Review and remove unused access
Common violation: "Just give them access to everything, easier that way." Creates massive over-permissioning.
2. Separation of Duties
Principle: Critical operations require multiple people. No single person can complete sensitive workflow alone.
Why it matters: Prevents fraud, mistakes, and insider threats.
In practice:
- Financial transactions: One person initiates, different person approves
- Production changes: One person creates change, different person deploys
- Access grants: One person requests, different person approves
Common violation: Same person who requests budget can approve budget can pay invoices. No separation.
3. Defense in Depth
Principle: Multiple layers of security. If one control fails, others still protect.
Why it matters: No single control is perfect. Layered controls catch what individual controls miss.
In practice:
- Authentication (SSO + MFA) + Authorization (RBAC) + Context (location/device checks) + Monitoring (anomaly detection)
- Network security + Application security + Data security
- Preventive controls + Detective controls + Corrective controls
Common violation: "We have firewall, that's enough." Single control is single point of failure.
4. Audit and Accountability
Principle: All access should be logged, traceable, and attributable to specific individuals.
Why it matters: Can't investigate incidents without knowing who accessed what when. Can't prove compliance without audit trails.
In practice:
- Log all authentication attempts
- Log all access grants and revocations
- Log all resource access (who viewed, modified, downloaded what)
- Retain logs for compliance periods
- Regular review of access patterns
Common violation: Shared accounts (no attribution), insufficient logging, no log review.
5. Regular Review and Recertification
Principle: Access should be reviewed periodically to ensure it's still appropriate. People change roles, projects end, access should change too.
Why it matters: Access creep—accumulation of permissions over time that are no longer needed. Creates over-permissioning and compliance risk.
In practice:
- Quarterly access reviews by managers
- Annual recertification for sensitive access
- Automated removal of unused access
- Access tied to employment status (auto-revoke on termination)
Common violation: Access granted but never reviewed. People retain access from every role they've ever had.
Common Implementation Approaches
Here's how most mid-market companies actually implement access control:
Approach 1: Manual Individual Permissions (Don't Do This)
How it works: IT manually grants access to each application for each user based on tickets.
Who uses this: Companies that haven't implemented systematic access control. Usually <50 employees.
Problems:
- Doesn't scale past 50 people
- Every hire/transfer/departure requires multiple manual tickets
- High error rate
- No consistency
- Impossible to audit
- IT spends all time processing access tickets
When acceptable: Never. Even at 10 employees, group-based is better.
Approach 2: Group-Based Access Control (Standard)
How it works: Create groups representing departments and roles. Assign users to groups based on HR attributes. Grant application access to groups.
Who uses this: Most mid-market companies (100-1,000 employees).
What you need:
- IdP (Azure AD, Okta, Google Workspace)
- HR integration (Workday, BambooHR, etc.)
- 20-40 groups (department + role + employment type)
- Dynamic group rules based on HR attributes
Advantages:
- Scales well
- Automates provisioning
- Auditable
- Manageable
When to use: Standard approach for most organizations. Start here.
Approach 3: Group-Based + Context (Advanced)
How it works: Groups define WHO has access. Context adds WHEN/WHERE/HOW—additional verification based on location, device, time, risk.
Who uses this: Organizations with remote workers, BYOD, compliance requirements, or security maturity.
What you need:
- Group-based foundation (must be working first)
- IdP with conditional access support
- Device management (for device-based policies)
- Understanding of access patterns
Advantages:
- Better security than groups alone
- Catches compromised credentials
- Adapts to risk level
When to use: After establishing clean group foundation. Not before.
Approach 4: Attribute-Based Policies (Specialized)
How it works: Fine-grained policies based on multiple attributes. Complex authorization logic.
Who uses this: Large enterprises, highly regulated industries, organizations with complex requirements.
What you need:
- Mature identity infrastructure
- Clean attribute management
- Policy authoring expertise
- Strong testing processes
When to use: Only if RBAC/GBAC + context can't meet requirements. Most organizations never need full ABAC.
What Good Access Control Looks Like
You know your access control is working when:
Provisioning is Fast
Good: New hire's HR record populates on start date. Within 1-3 hours, they have access to all applications they need based on department and role. Zero IT tickets.
Bad: New hire submits 10 tickets requesting access. IT processes over 2-3 days. New hire sits idle waiting.
Deprovisioning is Automatic
Good: Employee status changes to "terminated" in HR system. Access revoked across all systems within 1 hour. Complete and automatic.
Bad: IT gets termination notification. Manually removes access from each system they can remember. Takes days. Misses shadow IT. Former employee retains access for weeks.
Access Reviews Actually Happen
Good: Managers review their team's access quarterly. Reviews take 10-15 minutes per manager because groups are clear and scoped. Over-permissioned access found and removed.
Bad: Annual access review scheduled. Takes 6 weeks to complete. Managers approve everything because they don't understand what they're reviewing. Nothing changes.
Nobody Spends All Day on Access Tickets
Good: IT spends 2-3 hours per week on access exceptions (legitimate edge cases). Routine access is automated.
Bad: IT spends 15+ hours per week processing access tickets. Backlog always growing. Access management consumes IT capacity.
You Can Answer "Who Has Access?"
Good: "Who has access to production database?" → Pull report. 12 people in these 2 groups. Here's why each person should have it. Takes 30 seconds.
Bad: "Who has access to production database?" → Investigate for 3 days. Check multiple systems. Still not confident answer is complete.
Compliance Audits Are Easy
Good: Auditor requests access evidence. Generate reports from IdP and access management platform. Show audit trails. Demonstrate reviews. Pass audit.
Bad: Auditor requests access evidence. Scramble to manually compile data. Can't produce complete evidence. Fail audit.
Getting Started with Access Control
If you're implementing access control or fixing broken access control:
Step 1: Get Visibility
Can't fix what you can't see. First step is understanding current state:
- Which applications exist (including shadow IT)
- Who has access to each application
- How access is currently granted
- Which access is appropriate vs over-provisioned
Application discovery platforms like Zluri provide comprehensive visibility across your entire application portfolio—showing not just which apps exist, but who has access, at what permission levels, through which mechanism (IdP groups, direct assignments, app-native permissions).
This visibility is prerequisite for implementing systematic access control. Can't design groups without knowing what access patterns exist. Can't automate without knowing what needs automation.
Book a demo to see how comprehensive visibility enables effective access control for mid-market companies.
Step 2: Connect IdP to HR System
HR system should be authoritative for department, job title, employment status. IdP should sync this data and use it for group membership.
This enables automation—when HR data changes, access changes automatically.
Step 3: Design Group Structure
20-40 groups for most mid-market companies:
- 6-10 department groups
- 8-12 role groups
- 3-5 permission level groups
- 2-3 employment type groups
Simple, clear, mappable to HR attributes.
Step 4: Implement Dynamic Groups
Create groups that populate automatically based on HR attributes:
- Department attribute → Department groups
- Job title → Role groups
- Employment type → Employee vs contractor groups
Test thoroughly before using for access control.
Step 5: Migrate Applications to Groups
Move application access from individual assignments to group assignments:
- Map current access to group structure
- Migrate one application or department at a time
- Test before removing old assignments
- Verify nothing breaks
Step 6: Automate Provisioning and Deprovisioning
Connect group assignments to application provisioning:
- User joins group → Applications provision automatically
- User leaves group → Applications deprovision automatically
- Tied to HR data → Happens without IT tickets
Step 7: Implement Governance
Prevent chaos from recurring:
- Regular access reviews
- Automated unused access removal
- Group creation approval process
- Monitoring and refinement
Access control isn't one-time project. It's ongoing discipline.
The Bottom Line
Access control determines who can access what. It's implemented through combination of:
- Authentication: Proving identity (SSO, MFA)
- Authorization: Determining what that identity should access (groups, roles, attributes)
- Context: Adding dynamic factors to access decisions (location, device, time, risk)
Most mid-market companies should:
- Start with group-based access control (RBAC through IdP groups)
- Automate group membership from HR data
- Layer context-based policies on top once foundation is solid
- Only consider attribute-based policies if specific requirements justify complexity
Good access control is:
- Automated (minimal manual tickets)
- Fast (provisioning in hours, not days)
- Auditable (can answer "who has access to what" instantly)
- Scalable (works at 100 employees and 1,000 employees)
- Secure (least privilege, separation of duties, defense in depth)
Access control is foundational security. Get it right and everything else becomes easier. Get it wrong and everything else becomes harder.
Frequently Asked Questions
Q: What's the difference between authentication and authorization?
Authentication verifies identity — proving you are who you claim to be. Authorization determines what that verified identity is allowed to access. Authentication comes first; authorization happens after. Most access failures are authorization problems, not authentication problems.
Q: Which access control model should my company use?
For most companies between 100–1,000 employees: start with group-based RBAC. Create 20–40 groups mapped to departments, roles, and employment types. Automate group membership from HR data. Layer context-based policies on top once that foundation is stable. ABAC is only necessary if your compliance requirements or authorization complexity genuinely can't be handled by RBAC + context.
Q: What is least privilege and why does it matter?
Least privilege means users get the minimum access necessary to do their job — nothing more. It matters because every unnecessary permission is potential attack surface. When credentials are compromised, least privilege contains the blast radius. Without it, one phished junior employee can expose your entire environment.
Q: How often should we review access permissions?
Quarterly access reviews for standard permissions, with annual recertification for sensitive or elevated access. More importantly: tie access to employment status so deprovisioning is automatic on termination, not manual. Manual deprovisioning is where former employees retain access for weeks.
Q: What's the difference between RBAC and ABAC?
RBAC grants access based on assigned roles — Sarah is an Engineer, Engineers get GitHub, Sarah gets GitHub. ABAC grants access based on multiple dynamic attributes — Sarah gets the customer database only if she's in Customer Success, on a managed device, during business hours, from within the US. RBAC is simpler and sufficient for most companies. ABAC is powerful but complex — don't start there.
Q: What does "access creep" mean?
Access creep is the gradual accumulation of permissions over time that are no longer needed. Employee gets access for a project, project ends, access stays. They change roles, old access stays. Within a few years they have permissions from five different contexts with no clear justification. Regular access reviews exist specifically to catch and remove this.
Q: When should we implement conditional access policies?
After — not before — your group-based access control foundation is clean and working. Conditional access layers dynamic context (location, device, time, risk level) on top of role assignments. It adds meaningful security, but troubleshooting it becomes a nightmare if your underlying group structure is messy.
Q: How do we know if our access control is actually working?
Four signs it's working: new hires get all necessary access within hours of their start date without IT tickets; terminated employees lose all access within an hour of HR updating their status; managers can complete quarterly access reviews in under 15 minutes; and you can answer "who has access to X?" in under 60 seconds by pulling a report.
.svg)
