One sign-in for every app, and MFA that a phishing kit can't relay.
A help desk that resets passwords all day and an app list nobody can finish usually share a cause. We consolidate workforce sign-in on Okta, Microsoft Entra ID or Ping Identity, move people to passkeys, and write access policies your admins can read.
Identity and access management (IAM) controls how employees and contractors sign in and what each sign-in can reach.
Cohash designs and builds workforce IAM on Okta, Microsoft Entra ID and Ping Identity. That includes SSO for SAML and OIDC apps, phishing-resistant MFA with passkeys, conditional access policies, SCIM provisioning, and migrations between identity providers when a merger or a contract renewal forces the move.
you probably need this if
The help desk spends most of its day resetting passwords.
Nobody can finish the list of apps that still keep their own passwords.
MFA still relies on SMS codes or push prompts that a phishing kit can relay.
terms on this pageConditional accessdefinitionRules evaluated at each sign-in that look at conditions such as user, device or location, and then allow, block or demand more proof.explained in a field note →
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Identity & Access Management, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · identity & access management3 open
openThe help desk spends most of its day resetting passwords.
recurringNobody can finish the list of apps that still keep their own passwords.
blockedMFA still relies on SMS codes or push prompts that a phishing kit can relay.
exposure
SSO consolidationPhishing-resistant MFA and…Access policy designIdentity provider migrationsDirectory and tenant consolidationAdmin and break-glass hardening
startrehearsehandover
Measure
Design
Migrate in batches
Hand over
we are here
ready to hand over
Every app has one IdP of record now.
Relaying a push or a code no longer gets a phishing kit a working session, at least for…
Application inventory with federation status and owner
Authenticator strategy by user population, including recovery
chapter 01 · where it hurts
Why teams reach out
The help desk spends most of its day resetting passwords.
Nobody can finish the list of apps that still keep their own passwords.
MFA still relies on SMS codes or push prompts that a phishing kit can relay.
chapter 02 · what we change
How we solve it
SSO consolidation
Phishing-resistant MFA and passkeys
Access policy design
Identity provider migrations
Directory and tenant consolidation
Admin and break-glass hardening
chapter 03 · how it runs
Our approach
Measure
Design
Migrate in batches
Hand over
chapter 04 · where you end up
What changes
Every app has one IdP of record now.
Relaying a push or a code no longer gets a phishing kit a working session, at least for the groups that have moved.
Application inventory with federation status and owner
Authenticator strategy by user population, including recovery
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
We list every app that still keeps its own password, rank them by risk and user count, and move them to SAML or OIDC in batches. Apps that can't federate get a documented exception instead of being forgotten.
We roll out FIDO2 security keys, Windows Hello for Business and synced passkeys group by group, with a recovery process that never drops back to SMS. NIST SP 800-63B-4 caps synced passkeys at AAL2, so admins and high-risk roles get device-bound keys.
Entra Conditional Access or Okta authentication policies written as a small layered set, tested in report-only mode first, and kept in Terraform where the platform allows it.
Ping or ForgeRock to Okta, Okta to Entra ID, or the other way round. Both IdPs run in parallel, apps cut over one at a time, and each keeps a rollback path until its sign-in logs look clean.
Active Directory clean-up, Entra Connect or Cloud Sync design, and tenant merges after acquisitions, including guest accounts and cross-tenant synchronization.
Separate admin accounts. Emergency-access accounts that sit outside policy and alert the moment anyone uses them. An IdP admin console locked down as tightly as a domain controller.
capability 01 / 06in production
SSO consolidation
We list every app that still keeps its own password, rank them by risk and user count, and move them to SAML or OIDC in batches. Apps that can't federate get a documented exception instead of being forgotten.
We roll out FIDO2 security keys, Windows Hello for Business and synced passkeys group by group, with a recovery process that never drops back to SMS. NIST SP 800-63B-4 caps synced passkeys at AAL2, so admins and high-risk roles get device-bound keys.
Entra Conditional Access or Okta authentication policies written as a small layered set, tested in report-only mode first, and kept in Terraform where the platform allows it.
Ping or ForgeRock to Okta, Okta to Entra ID, or the other way round. Both IdPs run in parallel, apps cut over one at a time, and each keeps a rollback path until its sign-in logs look clean.
Active Directory clean-up, Entra Connect or Cloud Sync design, and tenant merges after acquisitions, including guest accounts and cross-tenant synchronization.
Separate admin accounts. Emergency-access accounts that sit outside policy and alert the moment anyone uses them. An IdP admin console locked down as tightly as a domain controller.
We pieced these together from Identity & Access Management situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Okta and Entra ID both in use, with no agreed source of truth
composite · not a client story
Beforethe situation
Microsoft 365 signs in through Entra ID, about 250 SaaS apps federate to Okta, and an Okta-to-Office 365 integration was set up and half abandoned. Users get two MFA prompts and admins aren't sure which IdP to change.
What we dothe work
Inventory every app by IdP from sign-in logs and pick one authoritative IdP per user population. Document which way federation runs and have one platform accept the other's MFA claim. Then move apps in batches, each with a rollback.
Afterwhere you end up
Every app has one IdP of record now. People get one MFA prompt, not two, and admins know which console to change. The exception list is short and written down.
case file 02
Push approval for everyone, and a help desk that resets MFA on request
composite · not a client story
Beforethe situation
Push approval is the only factor most staff have, and SMS is still on as a fallback. Anyone who rings the help desk with an employee ID and a manager's name can get MFA reset.
What we dothe work
Start with FIDO2 keys for admins and finance. Roll passkeys out group by group after that, tying enrollment to a verified session, and strip SMS from the policy as each group is done. The help desk stops resetting over the phone and issues a Temporary Access Pass only once ID is verified.
Afterwhere you end up
Relaying a push or a code no longer gets a phishing kit a working session, at least for the groups that have moved. Help desk staff follow a recovery script, and charm on the phone doesn't get anyone past it.
Where the workforce identity provider sits between people and apps
HR, the directory and managed devices feed the identity provider, which evaluates access policy at every sign-in. Federated apps receive a SAML assertion or OIDC token, and every sign-in lands in the SIEM.
01 · Sources
HR systemWorkday · SuccessFactors → Workforce IdP · user lifecycle
Access policiesConditional Access in Terraform → Workforce IdP · policy
03 · Applications
SAML appsSalesforce · ServiceNow
OIDC appsMicrosoft 365 · internal web apps
Apps that can't federatedocumented exceptions
04 · Logging
SIEMsign-in and admin audit logs
Read the diagram as text
HR system → Workforce IdP: user lifecycle
Directory → Workforce IdP: directory sync
Managed devices → Workforce IdP: device signal
Access policies → Workforce IdP: policy
Workforce IdP → SAML apps: SAML assertion
Workforce IdP → OIDC apps: OIDC token
Workforce IdP → Apps that can't federate: password exception
Workforce IdP → SIEM: sign-in logs
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Measure
App inventory from IdP logs, proxy data and finance records, MFA coverage by method, and a plain-language list of what each existing policy does.
step 02
Design
A target policy set and an authenticator choice per user population, plus a migration order agreed with app owners and the help desk.
step 03
Migrate in batches
We move apps and users in groups, never all at once. Sign-in monitoring runs throughout, and every group has a named person on call.
step 04
Hand over
Runbooks for onboarding apps, changing policy and recovering accounts, then a review session a month after the last batch.
you keep
What you're left with
We write these for your Identity & Access Management setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
inventory01
Application inventory with federation status and owner
yours to keep
document02
Authenticator strategy by user population, including recovery
yours to keep
guide03
Versioned conditional access or authentication policy set
yours to keep
runbook04
IdP migration runbook with rollback steps per app
yours to keep
code05
Help desk scripts for MFA enrollment and caller verification
talent and delivery · identity & access management
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your Identity & Access Management work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you test our Conditional Access changes before they reach real users?
One bad policy can lock out a whole tenant, admins included. Expect report-only mode, a pilot group, the What If tool, and an excluded emergency-access account that alerts on every use.
Q2
Which of our apps pin SAML signing certificates or metadata, and how will you find them?
IdP migrations fail on apps that hard-code the old certificate or entity ID. Those need app-owner time and their own cutover window, so they belong in discovery, not on cutover night.
Q3
What is the recovery flow for a user who loses their only passkey?
Phishing-resistant MFA is only as strong as the way people recover it. If recovery drops back to SMS or security questions, that's the door attackers will use.
Q4
How do you decide who gets device-bound keys instead of synced passkeys?
NIST SP 800-63B-4 caps syncable authenticators at AAL2. Admins and regulated roles may need device-bound keys, and that choice should match what your auditor expects.
Q5
Will our access policies live in Terraform, or only in the admin console?
Console-only policy has no review trail and is hard to roll back. Ask which Okta or Entra policy objects the Terraform providers will manage and which stay manual.
01Should we standardize on Okta or Entra ID for workforce sign-in?
Mostly on what's already there. Heavy Microsoft 365 shops with Intune-managed devices get device signals and bundled licensing from Entra ID that are hard to beat on price. Okta tends to fit mixed estates with lots of non-Microsoft apps and more than one HR source. Running both is common and fine, provided each user has one clear source of truth.
02How do we roll out passkeys without flooding the help desk?
Pilot with people who already have managed devices, publish a one-page enrollment guide, and fix recovery before you scale. Lost and replaced phones cause more tickets than enrollment does. A verified recovery flow, such as a temporary access pass issued after manager or ID verification, keeps those calls short.
03Do synced passkeys count as phishing-resistant for compliance?
Usually, with limits. NIST SP 800-63B-4, finalized in July 2025, allows syncable authenticators up to AAL2 but not at AAL3. Check what your auditor or regulator expects for privileged users before you choose synced over device-bound keys for them.
04How much downtime does an identity provider migration cause?
Very little for users when it's done app by app. Each app gets a test, a scheduled cutover and a rollback. The risk sits in apps with hard-coded metadata or signing certificates, and discovery is where we find those.
05Do you also handle access reviews and provisioning governance?
Yes. SCIM provisioning is part of this work. Certification campaigns, role models and separation-of-duties rules are covered on our identity governance page.
related
Often paired with
Projects on Identity & Access Management usually end up touching one of these, so they're worth a look.
