Why Provisionr Exists

How does this relate to me? Are any of these true?

• Do you sign in using Okta at work?
• Do you use Gmail or Google Drive at work?
• Do you wear multiple hats or work on multiple teams?
• Do you submit access request tickets to IT or Security?
• Does your IT or Security team want an IGA but can't afford it?
• Do you have to wait days or weeks for access to be provisioned?
• Are you still in your old team's mailing list or Google Drive folder?
• Does your entire department have access when only your team should?
• Why doesn't IT/Security know what your job is and what you should have access to?

Sound familiar? You're in the right place.

These are common pain points that many of the 9,000,000+ Google Workspace and 18,000+ Okta customer organizations face. If you're not on the IT or Security team, please feel free to share this page with them.

Have you heard of CRM or ERP software?

Identity Governance and Administration (IGA) software is the ERP-equivalent that your IT team needs to provision access to all of the application tiles and data that you're authorized to see after you authenticate with single sign-on (SSO). Without IGA software, every employee and contractor's access is usually provisioned by hand from a checklist or an access request by your IT or Security System Administrator team. Ask your IT team how many access request tickets they handled last month. The volume may surprise you.

Isn't this solved already?

For SSO application access, most birthright or baseline entitlement requests during onboarding are provisioned based on whether you're in the Finance, Sales, or Engineering department. That's not granular enough, and it's not your IT's fault. They simply don't have the tools to solve least privilege properly. Bulk provisioning is possible with the System for Cross-domain Identity Management (SCIM) protocol, but you're still missing the granularity.

Most access requests are for group membership, not apps and resources.

This builds on a similar principle to how permissions are assigned to roles, and users are assigned to roles instead of permission directly. Each group has already been assigned to the application or resource with the appropriate permissions.

Groups have group members and that list of users is the manifest or roster of who has access, and you are simply being added to the list of members for the group. If multiple groups have access, then we can see both the individual groups and the cumulative list of users, but instead of certifying that 500 users in the group are appropriate, we know that 490 of them were from a baseline entitlement group and the other 10 came from a separate group. This is the pain point with traditional CSV exports that compliance engineers spend weeks reconciling every quarter.

You need an enriched directory and multi-dimensional relationship policy engine.

How many hats do you wear? Your HRIS thinks you have one job title, but you might have 5-20 different least privilege roles. If your HRIS and IdP store this at all, it's plain strings in custom fields, not part of a true user profile schema that handles the lifecycle of joiner-mover-leaver (JML) processes. Your IdP isn't much better since it imported the data from your HRIS, and after a few access requests, you were granted access to a few more applications or resources as needed.

With the right foundation, you can have powerful Attribute-Based Access Control (ABAC) that knows what department you're in, what your job title is, who your manager is, what team(s) you work on, and what special projects that you need access to.

Group string matching rules are lightweight.

Most vendors support some lightweight form of group rules. Do you know which groups you are a member of? Maybe you've seen a group named sales-enterprise-emea? Your IT or Security team may have lightweight automation with group string matching rules division = Sales & department = Enterprise Sales & region = EMEA , and that's as complicated as Google Workspace and Okta support.

What happens if a string is renamed?

How many times have your sales regions or territories been renamed or re-architected in the last few years, or simply split into 2-3 subregions? All of the rules break every time it happens, and every annual Sales Kick Off event is usually a full rewrite.

Ask your Salesforce administrator how many hours they spend mapping sales regions to sales reps each year, now double or triple it and that's how long the IT tickets take (at least).

If we used immutable IDs instead of strings, it wouldn't be as fragile, but existing systems rarely support that well and it is still a lot of manual overhead.

Additional granularity is needed for least privilege.

We've seen how this gets complex pretty fast with manual administration. Now we need to talk about least privilege. That group has 30 people in it and it's assigned to everything related to Sales EMEA. Do they all need access to your Google Drive Folder for a specific customer in EMEA? Or only the 4 sales team members that work with that customer?

What about the sales-enterprise-emea-acme-co group? IT or Security may refuse to create it because it will be too overwhelming to maintain by hand based on what you have already seen with the recurring team restructuring, not to mention a new access request ticket each week as new customers sign up.

You need a system to manage those many-to-many database relationships for your attributes that supports more than one or two combinations, and built-in support for naming specific users to special project teams.

How does my organization likely do it today?

The stopgap solution that many teams have been using for years is to simply submit an access request ticket and it's evaluated by a human in IT or Security at the time of the request to determine if it's appropriate and provision it. It's a set it and forget it model (the ticket was resolved), and that access is usually only cleaned up during a compliance user access review (if they catch it).

How often do people change roles or move to a different team each year? How many new teams were created, renamed, or deprecated this year? Who is taking care of the housekeeping and cleanup of that access?

Built by sysadmins, for sysadmins.

Many organizations have hired an Identity Security team to work alongside IT to try to keep this chaos in order. Our CPTO understands that pain since he was the founding engineer on the Identity team at GitLab and founded Provisionr to solve the root cause of this pain point.

The teams at larger organizations exist, the conferences exist, but the tool to solve the underlying group member management and real-world advanced policy engine mechanics that IT and Security System Administrators need hasn't existed, until now.

Your IGA should be an ERP platform, not just your approval and reporting middleware.

Without an underlying directory and policy engine, an IGA is just a middleware that provides approval and reporting. You need a control plane. We believe that Identity Governance and Administration should give more attention to Administration, and if the Administration engine is solid then Audit comes naturally as a byproduct.

Traditional IGA is for Audit Evidence, Not IT Administration.

Very few vendors focus on group administration because they were written for the auditor and compliance lens, not the IT administration lens. The auditors are looking at the apps and cumulative list of who has access at a point in time, verifying that the current access is appropriate, and being able to trace back to the justification in the access request and appropriate approval that may have been rubber-stamped.

Modern IGAs are pretty, but they are treating the symptoms, not the root cause.

Modern IGAs have built on top of the audit and compliance-driven process with elegant access request approval engines and have not tried to fix the root cause. As an industry, we've over-rotated on "standing access" being a dirty word and have been promoting "the right access, at the right time, for the right reasons". However this is in the name of security, with no regard for the loss of productivity. Access sensitivity is a not a one-size fits all policy.

90% of access requests shouldn't exist in the first place.

If your policy engine is set up well and you administer the membership of the groups with information architecture that matches how your organization should properly implement least privilege, then what are all the access requests for? We don't believe in making the exception the standard process. You should require access requests for sensitive access, but with the right least privilege policy-based provisioning in place, you can automate most of it.

We believe the standard process should use the combination of Attribute-Based Access Control (ABAC), Policy-Based Access Control (PBAC), and Role-Based Access Control (RBAC) to administer the groups and group members, allowing your organization to easily attach least privilege groups to the applications, data, and resources needed.

Access provisioning should happen automatically when someone is hired or their job role is changing.

Why does everyone have to open 10-50 tickets for access that they heard from a coworker they might need? Your team has to invest the time to get your policies in place, but that's just automating one checklist a time at whatever pace works for you.

Once the engine is humming, everything happens automagically. Access revocation should happen in real-time as the business organically evolves, not be caught retroactively months later. You should audit and certify that the system mechanics of the policies are behaving the way it was supposed to, and spend less time focusing on verifying that the human followed the checklist or runbook in the right order.

That's where we come in.

Many teams buy point solution tools to handle directory, provisioning, audit review, and tickets separately. Provisionr has invented the Secure Human Identity Engine and Lightweight Directory (SHIELD), your Identity Information System that holds far more granular detail about who each person is and what they should have access to than your Human Resources Information System (HRIS) and Identity Provider (IdP) do, including the multi-dimensional relationships that define least privilege.

Our policy-based access control (PBAC) engine automates the provisioning and deprovisioning behind the manual access request tickets that come with onboarding and job role changes, ensuring least privilege access to applications, data, and systems for employees, contractors, and third-party collaborators.

Our platform provides the single pane of glass for Identity, Governance, and Policy Administration for organizations that use Google Workspace and/or Okta with 100 to 20,000 users.

IGA shouldn't require a big budget.

IGA software is usually too expensive ($10k-300k/yr) for smaller companies, and we don't believe it should be. Large companies need comprehensive Identity Governance, yet smaller organizations have the same automation and provisioning pain points. They only need the Evaluator or Essentials tiers at a flat price (from $20/mo) they can submit on an expense report.

One platform to rule all the groups

If you've read this far, we hope you appreciate the nerd humor. We're not going to boil the ocean and solve every problem for everyone, but we are going to make our dent in the universe with advanced policies for group membership and all of the downstream benefits that go with it.

We're on a mission to unify the granular human identity data that has been scattered across technologies invented 10-30 years ago throughout Lightweight Directory Access Protocol (LDAP), HRIS, IdP, IGA, SAML, and SCIM into one platform that is plug-and-play and affordable for teams of any size. Done right, we can reduce or remove the need for access requests entirely and automatically handle your user access compliance reviews.

Many of our competitors are focused on authentication, AI agent identity, and audit reports. We're solving for IT administration and policy-based authorization driven by group membership. We're not focused on all of the shiny new technology, because the fundamentals of security haven't changed and we want to fill the gap with group member management that nobody took the time to solve, and it's still the way that IT manages human identity.

Provisionr doesn't need hundreds of integrations.

We focus on the upstream groups (and group members) that grant access to all of those other integrated systems downstream by proxy.

If your organization uses Google, you belong to several or even dozens of Google Groups that manage your mailing lists, your access to Google Docs and Drives, shared Google Calendars, Google Cloud Projects, and more, including Google Workspace's 5,000+ integrations.

Okta uses groups to manage which users are provisioned for each SSO dashboard application tile across its 6,500+ integrations.

AWS Identity Center grants access to IAM account roles across your organization. GitLab uses groups to manage which code repositories your engineers can access. Slack uses groups to automatically add users to the channels their group already belongs to.

We have additional integrations on our roadmap, but we believe we can solve 80-90% of the pain points that we've felt before by focusing on enhancing our policy engine around our core integrations.

Do you need to ask for permission to play?

We've lived the IT life for decades. We know you don't have budget, but you do have a few hours of spare time to try new things and see if they work before you justify the spend on yet another tool. Our pay-as-you-grow model is built for exactly that, and the invoices for your first few months (or even years) are usually small enough to add to an expense report.

Create a free trial workspace to get started. The trial gives you the full platform for 30 days. We only ask that you connect your Google Workspace or Okta tenant within the first 5 days so the workspace isn't sitting abandoned.

You can start in read-only or read-write mode based on the API access you grant. See the Google Auth and Okta Auth docs to learn more. Even with read-only access, you can draft your policies and see a side-by-side comparison of the membership list, then provision read-write access later, once security approves, when you're ready to run your first sync.

We only sync the groups you explicitly activate a ruleset for; everything else stays in a staged/draft state for you to preview. Your policy can be additive, adding missing members without the authority to remove members that don't match, or authoritative, taking control of the group to match its members to the policy manifest while retaining a record of who existed before for easy restoration.

Our sync uses API polling. If your trial workspace expires or you remove Provisionr's API access, whatever state your groups are in is left alone. The syncing simply stops and you manage members on your own from that point forward. We don't delete or clean up a group or its members unless you explicitly deactivate that specific group. In other words, we disconnect, we don't destroy.

Our flat-rate pricing can be expensed.

We don't need your credit card until your 30 day free trial ends and you're ready to keep your workspace.

Every workspace is one flat monthly price. No per-seat math, no consumption meter, no quote builder. You pick the tier whose infrastructure and sync cadence fit, and every platform feature of that tier is included.

Evaluator is $20/mo for a serverless workspace with weekly syncs that removes "one more thing" from your onboarding checklist. We think that's a steal of a price.

Essentials is $200/mo with dedicated compute, database, and encryption key per workspace, weekday syncs, and same/next business day support.

Enterprise is from $3,000/mo for a dedicated GCP project with customer-managed encryption keys, always-on infrastructure, hourly syncs, SIEM export, and SLA priority support. In some cases that ties to your compliance or security budget rather than your HR or IT operations budget.

The Self-Service and Governance modules are flat-priced add-ons per tier (included with Evaluator), and Enterprise can add self-hosting in your own AWS account or GCP project.

All groups are audit-ready with exportable logs and a manifest of users. Not every workspace needs always-on infrastructure or the highest sync frequency. You pay for the isolation and freshness you actually need.

Our Enterprise and Customer-managed infrastructure has the same platform features and governance benefits at every tier. The only fundamental difference is infrastructure isolation, sync frequency, and support response times. If your organization needs dedicated infrastructure across compute, KMS, and network, that's Enterprise.

We're honest about what we're good at, and what we're not.

We're focused on organizations that use Google Workspace and Okta. We've lived it, we know it, and it's what we're good at. We don't support or touch the Microsoft ecosystem. That's our choice. If you use Microsoft Entra (formerly Active Directory) or Office 365, then there are many tools that help you solve the kinds of problems we're solving.

We're not a fit for every organization, however if our use cases align with your pain points, then we'd love to talk more. If we do this right, access request loathing will largely be a thing of the past, and the perception of IT will be that you have your house in order and it's one of the best onboarding and role change experiences of their career. We can help you make that possible.

Don't see the feature you're looking for? We're transparent with our product direction, feature roadmap, wishlist, and off mission features (what we've said no to). Feel free to reach out in our Slack community to chat with us about your feature ideas and feedback.

Already have an IGA vendor? You can run Provisionr alongside your existing IGA vendor so you don't throw a wrench in your next audit. Just treat us like the next generation of your onboarding scripts for now and see if it takes the burden off your checkbox runbooks.