User Provisioning and Deprovisioning Process
A user provisioning and deprovisioning process creates accounts for new hires and removes them when people leave. You run this workflow by linking your HR tool to a central identity directory. Most teams map job titles to group roles during this setup. They grant database and server permissions to whole groups at once. When group roles are too broad, users get standing rights they rarely need. Those extra permissions stay active every day and expand your risk surface. How a native user provisi
User Provisioning (SCIM) + Automated Deprovisioning: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A user provisioning and deprovisioning process creates accounts for new hires and removes them when people leave. You run this workflow by linking your HR tool to a central identity directory. Most teams map job titles to group roles during this setup. They grant database and server permissions to whole groups at once. When group roles are too broad, users get standing rights they rarely need. Those extra permissions stay active every day and expand your risk surface.
How a native user provisioning and deprovisioning process works
The workflow starts in your human resources system when a manager hires someone. That system stores the person's start date, department, and job title. Your identity directory reads that record and builds a base profile. Next, the directory assigns the profile to groups based on the department. Standard sync protocols then push that account out to cloud platforms and databases. Each target system creates a local user or maps the group to a role.
Role changes follow the same path when an employee moves to a new team. The HR record updates first, and the directory swaps the group memberships. Still, old local roles sometimes stick around if a sync job fails. When a person leaves the company, HR marks the profile as inactive. The directory then cuts off single sign-on and tells target apps to drop the user. Manual accounts created outside the central directory often survive this step. Admins must hunt down those local keys and delete them by hand.
What directory lifecycle workflows solve and what they miss
A clean lifecycle workflow solves the problem of who can log in. It stops former workers from logging in through the main sign-on page. It also saves admin time on day one by setting up basic app accounts. Auditors like this setup because it shows a clear trail of group assignments.
Yet this setup leaves a major gap inside active sessions. Directory sync rules only decide if a user has an active account. They do not check what a user runs after logging in to a database. A developer in an approved group can still run a destructive delete command. They can also query tables full of raw emails, phone numbers, and card numbers. Also, sync jobs do not revoke active database passwords or local SSH keys right away. Standing group roles give users all-day power when they only need ten minutes of work.
User Provisioning (SCIM) + Automated Deprovisioning: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Closing the gap between account setup and live commands
To fix this, teams must separate account existence from live session permissions. Your directory should still create the base user and handle sign-on. Still, you should strip standing admin roles out of the default group sync. Instead of granting full database roles for months, check every command in flight. Look at each query or shell command before the server runs it. Require a quick peer review when someone needs to run a risky write operation. Apply data masking rules in flight to rewrite emails and national IDs in query results. This approach keeps day-one setup fast while protecting production data during every session.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between provisioning and deprovisioning?
Provisioning sets up accounts, groups, and roles when a worker joins or changes jobs. Deprovisioning turns off those accounts and revokes keys when the worker leaves.
Why do orphaned accounts happen during offboarding?
Orphaned accounts happen when admins create local database or server users outside the main directory. When HR disables the main profile, those untracked local accounts keeps the session active.
How do we reduce risk from broad onboarding roles?
Keep default group permissions read-only or empty at onboarding time. Then require per-command approval and apply data masking to rewrite sensitive fields in results.