Security work that starts where most attacks do, at the sign-in.
We're engineers who build and run identity and security platforms. Workforce sign-in, privileged access, customer login, service accounts and AI agents sit in one practice here, next to the detection, network and compliance work that depends on them.
Cohash designs, builds and upgrades the systems that decide who and what can sign in and what each can reach. That means workforce IAM, governance, privileged access, customer identity, and identity for machines and AI agents. We tune detection around that core, segment networks, and map controls to NYDFS Part 500, PCI DSS 4.0.1 and similar rules. Audit evidence then comes from systems that already run.
terms on this pageZero trustdefinitionA security model where nothing is trusted just because of where it sits. Every request gets checked against current evidence about the user, the device and the context.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 Cybersecurity, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · where you end up
incident board · cybersecurity3 open
openOkta, Entra ID, a PAM vault and a SIEM were each bought by a different team, and nobody owns how they connect.
recurringSeveral security features you already license were never switched on.
blockedYou have more service accounts and AI agents than employees. None of them show up in access reviews.
exposure
Workforce identity and governancePrivileged accessCustomer identityNon-human and AI agent identityDetection and responseNetworks, zero trust and…
ready to hand over
Every control has an owner and a written scope now.
There's a date for scoping down or retiring the two-way trust.
chapter 01 · where it hurts
Why teams reach out
Okta, Entra ID, a PAM vault and a SIEM were each bought by a different team, and nobody owns how they connect.
Several security features you already license were never switched on.
You have more service accounts and AI agents than employees. None of them show up in access reviews.
chapter 02 · what we change
How we solve it
Workforce identity and governance
Privileged access
Customer identity
Non-human and AI agent identity
Detection and response
Networks, zero trust and compliance
chapter 03 · where you end up
What changes
Every control has an owner and a written scope now.
There's a date for scoping down or retiring the two-way trust.
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Single sign-on, MFA and lifecycle automation on Okta, Microsoft Entra ID and Ping Identity. SailPoint or Saviynt get added once you need certifications and separation-of-duties rules.
We set up vaulting, session control and just-in-time elevation for admins on CyberArk, BeyondTrust or Delinea, so standing admin rights stop being the default.
We build sign-up, login and account recovery for the apps your customers use, on Auth0 or Microsoft Entra External ID, and connect it to your CRM.
Service accounts, workload credentials, certificates and AI agents get an accountable owner, credentials that expire, and a place in your access reviews.
We do identity threat detection and SIEM detection engineering. Rules live in version control and get tested against the attacks you actually lose sleep over.
Segmentation, private application access in place of flat VPNs, and control mapping for whichever regulations your auditors cite.
capability 01 / 06in production
Workforce identity and governance
Single sign-on, MFA and lifecycle automation on Okta, Microsoft Entra ID and Ping Identity. SailPoint or Saviynt get added once you need certifications and separation-of-duties rules.
We set up vaulting, session control and just-in-time elevation for admins on CyberArk, BeyondTrust or Delinea, so standing admin rights stop being the default.
Service accounts, workload credentials, certificates and AI agents get an accountable owner, credentials that expire, and a place in your access reviews.
We do identity threat detection and SIEM detection engineering. Rules live in version control and get tested against the attacks you actually lose sleep over.
We pieced these together from Cybersecurity situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Four identity tools bought by four teams, and an MFA finding on repeat
composite · not a client story
Beforethe situation
Okta runs workforce SSO, Entra ID came with Microsoft 365, a CyberArk vault covers about half the domain admins, and Sentinel ingests logs from all three. Internal audit has raised the same MFA coverage finding two years running.
What we dothe work
Start with a control inventory: which Conditional Access and Okta policies are live, which CyberArk safes actually rotate, which log sources feed a rule. Then name one owner per integration point and close the MFA gap on the apps audit sampled, before anyone buys a new product.
Afterwhere you end up
Every control has an owner and a written scope now. The finding that kept coming back closes on IdP sign-in evidence. Next time someone wants to buy a tool, they bring the gap list.
case file 02
A merger brings a second Entra tenant and 3,000 unowned service accounts
composite · not a client story
Beforethe situation
The acquired company runs its own Entra tenant and an on-premises AD forest joined by a two-way trust. Neither side can name owners for most of its service accounts, and the deal team set the integration deadline.
What we dothe work
Map the trust and the privileged groups in both forests first, because that is where an attacker would cross. Then set up cross-tenant synchronization for collaboration, vault the acquired Tier-0 accounts, and start the service account owner hunt from sign-in logs.
Afterwhere you end up
There's a date for scoping down or retiring the two-way trust. Admins from the acquired company now use the same PAM and MFA as everyone else. Every service account has either an owner or a disable date.
How identity connects the rest of a security program
People, customers and workloads authenticate through identity, privileged access and secrets platforms before they reach any system. Every one of those controls sends logs to the SIEM, which also feeds the evidence your auditors ask for.
01 · Identities
Employees and contractorsHR-sourced accounts → Workforce identity provider · SSO and MFA
Customersweb · mobile apps → Customer identity · login
Workloads and AI agentsservice accounts · CI · agents → Secrets vault · secret lease
Put these to anyone bidding on your Cybersecurity work. The ones who've done it answer differently from the ones who've read about it.
Q1
Who on your team will touch our production IdP tenant, and under what change process?
Every login depends on that tenant. Ask for the names and seniority of the engineers making changes, and how they roll back in an emergency, before the statement of work is signed.
Q2
Which licenses do we already own that you'd switch on before recommending a new product?
Many estates already pay for Conditional Access, Entra PIM, ID Protection or session recording that sits idle. A partner who leads with a purchase may be solving their quota rather than your gap.
Q3
How will you split configuration ownership with our MSSP or other integrators?
When two firms edit the same Okta policies or Sentinel analytics rules, you get outages and then finger-pointing. Write down one owner per platform and per change type to prevent it.
Q4
What evidence will our auditors get from this work, and from which system?
Build a control without an evidence path and someone ends up re-proving it with screenshots every year. The answer here should name actual reports in the IdP, IGA platform or SIEM.
Q5
Where will your detection rules and Terraform live when the engagement ends?
If the code sits in a partner's repository or depends on their tooling, you've bought a black box. It belongs in your own Git, with tests and a README your team can actually follow.
01We already own several security tools. Where would you start?
With an inventory of what's actually switched on. Plenty of estates pay for conditional access, privileged identity management or session recording that was never configured. We map which controls are live, which are licensed but idle, and which gaps really need a new product. That usually reorders the plan.
02Can you work alongside our managed security provider or another integrator?
Yes. We often take one slice, such as an identity provider migration or a PAM rollout, while another firm runs monitoring. We agree in writing who owns which configuration so changes don't collide.
03What drives the cost of a security engagement?
Integration count matters most. That means the number of applications, directories, privileged accounts or log sources in scope. Data quality comes next, because a clean HR feed or an accurate CMDB shortens almost every identity project. We estimate after a short discovery instead of from a rate card.
04Do you work with regulated companies?
Yes, and regulation drives much of the design. We map identity and logging controls to NYDFS Part 500, PCI DSS 4.0.1, HIPAA, NERC CIP and CMMC. Our governance, risk and compliance page tracks where each one currently stands.
05Can you run identity platforms for us after the build?
Yes, platform by platform. Think app onboarding, policy changes, upgrade testing and on-call when sign-in breaks. Response times and the changes that need your written sign-off get agreed in advance. And we still hand over runbooks, so leaving us is easy.
06How do you handle access to our environment during an engagement?
We work through accounts you issue, under your own MFA and PAM controls, with named engineers and admin roles that expire. Most tasks don't need standing Global Administrator or domain admin rights. The few that do, we'll name before the work starts.
related
Often paired with
Projects on Cybersecurity usually end up touching one of these, so they're worth a look.
