- Zen IT Technologies
- Identity & Access Management
One source of truth for who can reach what.
Identity is the control plane. When it is fragmented across three directories, a spreadsheet, and whoever remembers to remove access on someone's last day, every other control you have is decorative.
We migrate identity platforms, federate the applications that matter, automate provisioning end to end, and hand back an estate where access is derived from role, not from history.
The problem
Most identity estates were never designed. They accumulated.
A directory chosen in year one. A second one added when the first could not manage Macs. SSO on the six applications someone got around to, and local passwords on the forty that followed. Offboarding that depends on a checklist someone maintains manually.
The symptoms are recognizable:
-
Accounts that outlive employment.
Departed users still holding active sessions in SaaS applications nobody inventoried.
-
Manual provisioning at scale.
New hires waiting a day for access, and IT hand-creating accounts in a dozen systems.
-
Standing privileged access.
Admin rights granted for a project three years ago and never revoked.
-
More than one source of authority.
Running several platforms is often deliberate and correct. Device management and application access have genuinely different requirements. The problem is when two of them both believe they own identity, and reconciliation happens by eye.
-
Audit questions you cannot answer.
An auditor asks who had access to what, and when, with no system able to answer.
What we do
- User
- IdP
- SaaS
- Device
SCIM provisioning and lifecycle
-
Platform migration
Full migrations between identity platforms: JumpCloud to Okta, Google or on-premises directory to Entra ID, and the consolidation of parallel directories behind one authoritative source. Planned as a sequenced cutover with rollback at every stage, not a weekend gamble.
We handle the parts that break: password and session continuity, device-object reconciliation, group model translation, and the applications whose federation config nobody documented.
-
Choosing the platform: SSO or IdP
Most platform comparisons are answered at the wrong level. The question is not which vendor is better. It is whether you need single sign-on or an identity provider, because those are different products that happen to overlap.
If the requirement is authentication, SSO answers it: users reach applications with one credential, MFA is enforced consistently, and access is revoked in one place. Several platforms do this well, and nothing in that requirement obliges you to make a new identity platform your system of record. Paying for more than that is paying for capability you will not configure.
If identity itself needs to be the system of record, that is an identity provider, and it is a different architecture: lifecycle driven from HR, entitlements derived from role, deep SCIM against applications that implement the standard loosely, conditional access on device and context signals, custom authorization servers for your own APIs, and delegated administration that survives an audit. This is where Okta differentiates itself from lighter platforms: not in sign-on, but in everything downstream of it.
Running more than one platform can be entirely correct. Device management, directory services, and application access have different requirements, and the best tool for each is not always the same vendor. What cannot be split is authority: one identity platform should be authoritative for downstream identity and access state, even when employment status originates in HR, with other platforms consuming from that authority rather than maintaining an independent lifecycle.
Sometimes the answer is that your current platform is fine and the problem is how it is configured.
-
SSO and federation
SAML and OIDC integration across your SaaS estate, including the awkward ones: custom authorization servers, API scope design, applications with partial standards support, and platforms requiring bespoke claim mapping.
We prioritize by risk rather than by ease, so the systems holding your source code, customer data, and money get federated first.
-
SCIM provisioning and lifecycle
Automated joiner, mover, and leaver flows driven from your HR system through identity into every downstream application. Access is granted by role on day one and revoked completely at termination, without a human remembering to act.
This includes HRIS integration, group model design, license assignment automation, and the reporting that proves the lifecycle actually ran.
-
IT Workflow & Process Automation
Processes that connect IT with People & HR, Operations, Finance and other teams: onboarding, role changes, offboarding, approvals, equipment, access and recurring administrative work. We identify what should be owned by IT, automate what should not be manual, and make responsibilities clear between departments.
-
Access review and privileged access governance
Point-in-time reviews of who holds what, including the grants that never went through a process. We map every entitlement, identify standing privilege, design a group model that replaces individual assignment, and establish a review cadence your leadership can own.
The output is auditor-ready: an entitlement inventory, a remediation log, and a documented process.
-
Vendor Review and Vendor Management
Security assessment of prospective and existing vendors: certification validation, SOC 2 report review, SSO/SCIM readiness, and data-handling posture. Risk ratings, exception memos, and security questionnaires for the procurement file. We also manage those relationships beyond the initial review: technical onboarding, escalations, and renewal conversations.
Technical notes
Single sign-on is the easy half
Authentication is solved. Knowing which accounts should exist is not.
How it runs
-
Discovery.
A documented inventory of directories, applications, entitlements, and device objects. You find out what you actually have, which is usually more than expected.
-
Design.
Target-state architecture: authoritative source, group model, federation priority order, and provisioning flows. Written, reviewed, and agreed before anything moves.
-
Migration.
Sequenced cutover, application by application, with validation gates and rollback defined at each step.
-
Governance.
The review cadence, runbooks, and reporting are handed to your team, or managed with you, depending on the engagement.
Proof
-
Identity and device management separated without a disruptive migration.
Cybersecurity company
Authentication and endpoint management had become tightly coupled to a single platform. The architecture was separated so identity could move to a modern provider while the existing device-management estate continued operating throughout the transition.
-
Standing access replaced with role-driven control.
Fintech
Access mapped across a complex SaaS environment, individual grants replaced with role-derived groups, and a repeatable review process handed to the internal team.
-
An application without enterprise identity support brought under central authentication.
Technology company
A platform that could not meet the required identity model was integrated through an alternative architecture, bringing authentication and user lifecycle control back under the organization's central identity environment.
-
A fragmented access model replaced with lifecycle-driven access.
Technology company
Applications moved to role and group-derived access with automated provisioning and centralized authentication. Standing access was reduced, and onboarding and offboarding became predictable rather than manual.
Client examples are anonymized by design. References are provided privately, on request, and with the client's consent.
Who this is for
This is usually the point to act when:
Your headcount and SaaS estate are growing faster than the identity model behind them.
More than one system can grant access, but nobody can clearly say which one is authoritative.
An audit or customer security review is asking questions your current process cannot answer cleanly.
Migration is a project. Identity is ongoing. We work embedded with your team because identity is the layer the rest of your environment depends on.
Frequently asked questions
-
Do we need an identity provider, or is SSO enough?
SSO solves the authentication layer: one sign-in path, consistent MFA, and a central place to block new federated sign-ins. A full identity platform adds lifecycle control around that authentication: HR-driven joiner, mover and leaver flows, role-based entitlements, provisioning, conditional access, and application access policy. If you only need the first, paying for the second buys capability you will not configure.
-
Is it a problem to run more than one identity platform?
Not necessarily. Device management and application access have genuinely different requirements, and the best tool for each is not always the same vendor. What cannot be split is authority. One identity platform should be authoritative for downstream identity and access state, even when employment status originates in HR. Other platforms consume from that authority rather than maintaining an independent lifecycle.
-
How long does a platform migration take?
Weeks rather than days, driven by the number of federated applications and the complexity of the group model rather than by the platform itself. The migration is sequenced application by application with rollback at each stage, so there is no single cutover date to survive.
-
Can we run both platforms during the migration?
Yes, and usually you should. Parallel operation with one authoritative source is how a migration stays reversible. The temporary overlap adds license cost, but it reduces cutover risk and is usually a better trade-off than forcing a single-day migration.
-
What is SCIM and do we actually need it?
SCIM is the standard that lets your identity platform create, update, and deactivate accounts in downstream applications automatically. You need it when manual provisioning has become a bottleneck or when offboarding completeness has become an audit question, which for most companies happens at the same time.
-
Which platforms do you work with?
For information services platforms, we work with Microsoft 365, Google Workspace, Okta, JumpCloud, Atlassian, Mimecast, Jamf, Salesforce, and comparable platforms. The platform itself is only part of the picture. What matters is who owns identity, how access is granted and removed, and how the systems connect.
Find out what your identity estate actually contains.
A 30-minute call with Jonny, followed by a written baseline of your directories, applications, and entitlements if it is a fit. We reply within one business day.