The layer that blocks
more deals than model quality
Nobody has ever lost an enterprise deployment because the model scored two points lower on an eval. They lose it because the security reviewer asked “what happens to access when someone leaves?” and the honest answer was “you email us”. Identity is the least glamorous thing an FDE owns and the most reliable way to be blocked for six weeks by a team that does not report to anyone you have met.
Why this lands on the FDE
In a self-serve product, identity is a platform team’s problem solved once. In a deployment it is different every time, because it is their identity provider, their group taxonomy, and their security team’s rules. The FDE is the only person who is inside both organisations, so the integration lands on you whether or not it is in your job description — and the frontier-lab job descriptions increasingly say so out loud, listing enterprise integration alongside the AI work.910
Authentication — how does a human prove who they are? Provisioning — how do accounts get created and, far more importantly, destroyed? Authorisation — what is this person allowed to do, expressed in a way their admins can change without calling you? Workload identity — how does your software prove who it is to their systems, without a secret pasted into a config file?
Every objection a security reviewer raises is one of those four in disguise. Being able to name which one you are being asked about shortens the meeting considerably.
Identity work gets discovered during the security review, which happens near the end, which is when the timeline is already fixed. Ask the identity questions during scoping instead — “which IdP, do you require SCIM, and who approves an app registration?” takes ninety seconds and routinely surfaces a four-week dependency that would otherwise appear the week before go-live.
SAML or OIDC — and when you get no choice
Both prove who a user is. They disagree about almost everything else, and the customer usually decides for you.
| Dimension | SAML 2.0 | OIDC (OAuth 2.0) |
|---|---|---|
| Age / shape | 2005, XML, browser POST redirects | 2014, JSON + JWT, built for APIs and mobile |
| Typical use | Web SSO into an enterprise app | Web, native, machine-to-machine, token exchange |
| Who asks for it | Established enterprises, government, anything with a 2010-era IdP | Newer estates, anything mobile, anything API-first |
| Signature model | XML-DSig over an assertion — famously easy to validate wrongly | JWS over a compact token, standard libraries |
| Session logout | Single Logout exists and is unreliable in practice | Back-channel logout, better but not universal |
| Your effort | Metadata exchange, certificate rotation, attribute mapping | App registration, scopes, consent, token validation |
The practical answer: support both, lead with OIDC, expect SAML. A large regulated customer with a mature Active Directory Federation Services or an old Okta tenancy will hand you SAML and no alternative. Arguing costs you goodwill and does not change the outcome.
1. validate the signature on the assertion, not only on the response wrapper
2. check Audience, Recipient, NotBefore/NotOnOrAfter, and InResponseTo
3. reject unsigned assertions outright — no "fall back if absent" branch
4. pin the IdP certificate and calendar its expiry; rotation is the #1 cause of a
"nobody can log in this morning" incident 12–24 months after go-live
5. map attributes explicitly; never trust a display name as an identifier
Email addresses change — people marry, companies rebrand, an acquisition rewrites every address in the directory. Key your user records on the IdP’s immutable subject identifier (oid in Entra, NameID with a persistent format in SAML) and treat email as a display attribute. Retrofitting this after a customer’s domain migration is a data-repair project nobody has budgeted for.
SCIM: the question that actually decides the deal
“What happens when someone leaves?” If your answer contains the word “email”, you have failed the security review.
SSO answers who is this. It does not answer should this person still have an account. A user removed from the customer’s directory can no longer log in via SSO — but their account, their API tokens, their scheduled jobs and their data exports all still exist in your system unless something removes them. SCIM is the standard that closes that gap, and enterprise buyers with a compliance function will ask for it by name.
POST /scim/v2/Users create
GET /scim/v2/Users?filter=... lookup by userName (they will filter; support it)
PATCH /scim/v2/Users/{id} partial update — this is how deactivation arrives
DELETE /scim/v2/Users/{id} hard delete — many IdPs never call this
PATCH /scim/v2/Groups/{id} membership changes, add/remove operations
# the field that matters more than all the others
{"op":"replace","path":"active","value":false} ← deprovisioning is usually THIS,
not a DELETE. If you only implement DELETE, offboarding silently does nothing.
Get right the first time
active:falsemust revoke sessions and API tokens, not just block new logins.- Support
PATCHwith the operations syntax — Entra and Okta both use it heavily. - Be idempotent. IdPs retry, replay, and resend the same operation.
- Return the right status codes: 409 on duplicate
userName, 404 on unknown id. - Log every SCIM operation. It is the evidence trail an auditor asks for.
Costs weeks when wrong
- Treating deactivation as a soft flag your app then ignores at the API layer.
- Ignoring group membership, so authorisation drifts from the directory within a month.
- Non-idempotent creates — the IdP retries and you get duplicate users.
- No pagination on
GET /Users, which breaks the moment the tenant has 5,000 people. - Assuming your SSO provider handles SCIM for you. Verify. Often it does not.
Say so plainly and offer a compensating control with a date: a scheduled directory reconciliation job that deactivates any user no longer present, running daily, with a log the customer can inspect. Security reviewers accept a documented compensating control with an owner and a roadmap date far more often than people expect. What they do not accept is a vague assurance — and they will find out either way, because they test it.
Authorisation that survives a reorg
Their groups change every week. Your roles must not.
The instinct is to map their groups directly to permissions in your system. It works for a month. Then a reorg renames FIN-AP-ANALYSTS to FIN-OPS-AP-TIER1, nothing works, and the FDE gets paged for a directory change nobody told them about. The fix is an indirection layer that a customer admin can operate without you.
their directory groups FIN-AP-ANALYSTS, FIN-AP-MANAGERS, IT-PLATFORM-ADMIN
↓ a mapping table their admin edits in a UI
your roles reviewer · approver · administrator
↓ fixed, versioned, part of your product
your permissions document:read · document:approve · settings:write · export:all
Three roles is usually enough at go-live, and three roles that the customer understands beats twelve that only you can explain. Add the fourth when someone asks for it with a concrete case, not in anticipation.
Ask for the group list before you design anything
Not the org chart — the actual security groups, with membership counts. What people say the structure is and what the directory contains diverge more often than not, and the directory is what your code will see.
Default to deny, and make the empty state safe
A user who authenticates successfully but matches no group mapping gets no access and a clear message telling them who to ask. The failure mode where an unmapped user silently receives the default role is how data leaves the wrong department.
Make the mapping self-service and auditable
A screen their IT admin can use, with every change logged and attributed. This single screen removes you from a recurring support loop that otherwise lasts as long as the engagement.
Handle data-level scoping separately from roles
“Approver” is a role. “Approver for the EMEA entity only” is a data boundary, and cramming it into the role name produces a combinatorial explosion within two quarters. Keep the two axes apart from the start — retrofitting row-level scoping is a schema migration.
Workload identity: your software proving who it is
Human SSO is half the problem. The other half is the service account nobody rotates.
Your deployment reads from their data warehouse, writes to their object store, and calls a model endpoint. Each of those is an authentication decision, and the default answer — a long-lived credential in an environment variable — is the finding that appears in every security report ever written about an enterprise deployment.
| Approach | What it costs you | When it is the right call |
|---|---|---|
| Static key in config | Rotation is manual and therefore never happens; the key appears in a log or a screenshot eventually | Never, in a customer environment. It is a finding waiting to be written. |
| Secrets manager (Vault, Secrets Manager, Key Vault) | One dependency, one access policy to negotiate | The realistic baseline. Ask which one they run — they have one. |
| Cloud-native workload identity (IRSA, workload identity federation, managed identity) | Setup with their cloud team, one-time | The correct answer when you deploy into their cloud. No secret exists to leak. |
| mTLS / SPIFFE | Real infrastructure work and a CA conversation | Mature platform teams and service meshes; do not propose it into a team that has neither. |
Do not ask their cloud team for “access to the warehouse”. Send them the exact list: these three tables, read-only, from this service account, from this subnet. A specific request gets approved in days because it is easy to review; a broad request gets escalated, then debated, then trimmed by someone who does not know what you need — and you find out what they trimmed at runtime. Writing the narrow request is also the fastest way to discover you asked for something you did not need.
Identity is what the security review is really about
The questionnaire and the CISO call are where these decisions get tested. The gauntlet lab runs both against a deployment like yours.
The evidence a reviewer will ask you for
Enterprise security reviews are largely a request for artefacts. Having them ready converts a three-week back-and-forth into one call, and preparing them takes an afternoon.
An identity architecture diagram
One page: IdP, protocol, what claims flow, where the session lives, how tokens are validated, what talks to what with which identity. Reviewers approve things they can picture.
A joiner/mover/leaver walkthrough
Three paragraphs describing what happens in your system when someone is hired, changes team, and leaves. The third one is the one they care about, and the answer must include a time bound.
An audit log sample
Actual redacted lines showing authentication events, permission changes and data access, with the retention period stated. “We log everything” is not evidence; ten lines are.
A break-glass procedure
What happens when their IdP is down and someone must get in. Every reviewer asks, because the honest answer is often an undocumented local admin account, and they know it.
A named gap list
What you do not support yet, with dates. Volunteering this is counter-intuitive and it works — it is the single strongest credibility signal available in a security review, because the reviewer’s job is finding what you did not mention.
App registration in a large enterprise IdP is not a technical task, it is an approval chain — commonly two to four weeks, occasionally a quarterly review board. Start it in week one alongside discovery, before you have anything to register. The request costs you an email; discovering the queue in week eight costs you the launch date.
Quick answers
Should an enterprise integration use SAML or OIDC?
Support both, lead with OIDC, and expect SAML. OIDC is JSON/JWT-based, better for APIs, mobile and machine-to-machine flows. SAML 2.0 is XML-based and still what large regulated enterprises with mature Active Directory or older Okta tenancies will hand you — usually with no alternative offered. The customer’s identity provider decides, not you.
Why does SCIM matter so much in enterprise deals?
SSO answers who a user is; it does not answer whether they should still have an account. A user removed from the customer directory can no longer sign in, but their account, API tokens and scheduled jobs persist unless something removes them. SCIM automates provisioning and, critically, deprovisioning — which usually arrives as a PATCH setting active to false rather than a DELETE. If you only implement DELETE, offboarding silently does nothing.
How should you map a customer’s groups to roles in your product?
Never map directory groups straight to permissions. Put a mapping table in between that a customer admin can edit: their groups map to your small fixed set of roles (typically three at go-live), which map to permissions. Directory groups get renamed in reorgs; your roles must not change with them. Keep data-level scoping — such as "approver for EMEA only" — on a separate axis from roles, or the role list explodes combinatorially.
How should a deployed application authenticate to customer systems?
Prefer cloud-native workload identity (IRSA, workload identity federation, managed identity) when deploying into their cloud, because no secret exists to leak. Otherwise use their existing secrets manager. Never use a long-lived static key in a config file or environment variable — it is the finding that appears in every enterprise security report, because rotation becomes manual and therefore never happens.
When should identity work start in a deployment?
During scoping, in week one. Identity is normally discovered during the security review, which happens near the end when the timeline is fixed. Asking "which IdP, do you require SCIM, and who approves an app registration?" takes ninety seconds and routinely surfaces a four-week approval dependency. App registration in a large enterprise is an approval chain of two to four weeks, sometimes gated on a quarterly review board.
Sources
Every number on this page traces to one of these. Where a figure is self-reported or crowd-sourced rather than first-party, it is labelled inline.
Cited on this page
- OpenAI — Forward Deployed Engineer job description — “full arc of a deployment”. openai.com/careers/forward-deployed-engineer-(fde)-nyc-new-york-city/
- Anthropic — Forward Deployed Engineer, Applied AI (JD) — 40/30/30 split; MCP servers, sub-agents and agent skills as deliverables. jobs.menlovc.com/companies/anthropic/jobs/69674588-forward-deployed-engineer-applied-ai
- Anthropic — Forward Deployed Engineer, Federal Civilian (JD) — air-gapped and IL-level deployment requirements. jobs.menlovc.com/companies/anthropic/jobs/76278352-forward-deployed-engineer-federal-civilian
Explore the topic
See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.
More Handbooks
- The Prompting HandbookA friendly, hands-on field guide for everyday humans — learn the CRISP framework, spot bad prompts, practice with real recipes, play a drag-and-drop game, and test yourself with a quiz. No code required.Read →
- The Agentic AI Interview HandbookTwenty topics every senior AI engineer should be able to reason about live — from eval pipelines to reliability patterns for generative systems.Read →
- The Senior AI Engineer Interview Handbook60 questions across architecture, production incidents, agentic systems, RAG, evals, cost, safety, and leadership — what staff-level AI interviewers actually probe for.Read →
- 50 Angular Interview QuestionsA visual handbook covering components, change detection, RxJS, signals, routing, forms, performance, and testing — what interviewers actually probe for in senior Angular roles.Read →
- 50 Python Interview QuestionsFundamentals to advanced: data structures, OOP, iterators & generators, the GIL, asyncio, memory, testing, and the standard library — a visual walk through everything a Python interview touches.Read →
- 51 LLM Evals Interview QuestionsGolden sets, LLM-as-judge, regression testing, offline vs online evals, RAG evals, agent evals, red-teaming, and observability — demystified for interviews and production.Read →
Explore more from Vibe Engines
Get the next one in your inbox.
New handbooks, system-design walkthroughs, and tools — straight to your inbox. No spam, unsubscribe anytime.