By NHI Mgmt Group Editorial TeamPublished 2026-01-14Domain: Governance & RiskSource: WorkOS

TL;DR: Latacora argues startups usually need several security specialisations over time, not one mythical first hire, and says long-term embedded support prevents architectural mistakes that later turn into years of bug-hunting, according to WorkOS. The real shift is from reactive ticket closing to security shaped at design time, before bad assumptions harden into lasting exposure.


At a glance

What this is: This is an interview about fractional security for startups, with the central finding that embedded specialists prevent architectural mistakes better than a single generalist hire.

Why it matters: It matters because IAM, NHI, and human access programmes all fail when security is treated as a lone role instead of a sustained governance capability with the right specialist coverage.

👉 Read WorkOS's interview on Latacora and startup security without a unicorn hire


Context

Startups often treat security hiring as a single-seat problem, but identity and cloud security rarely behave that way. Application security, cloud posture, incident response, secrets handling, and access governance are different disciplines, and the failure mode is predictable: one generalist is expected to cover all of them before the organisation has the maturity to support that model.

The article's core point is that this gap is structural, not personal. When security work arrives as isolated emergencies rather than embedded design input, teams accumulate avoidable architectural debt across IAM, NHI, and developer workflows. The result is not just more findings, but more fragile identity assumptions that stay in place for years.


Key questions

Q: How should startups structure security coverage before hiring a full team?

A: Startups should divide security into distinct capability areas, then decide which ones need continuous ownership and which can be covered by embedded specialists. The key is to avoid assuming one generalist can hold every domain at once. A workable model gives the company access to depth when needed, while preserving clear accountability for architecture, incident response, and identity governance.

Q: Why do early architecture decisions matter so much for identity risk?

A: Early architecture decisions often determine whether identity and application risks become temporary issues or permanent programme debt. A design choice that narrows attack paths, data exposure, or trust boundaries can eliminate years of future remediation. Once those decisions harden into production systems, later reviews usually surface the problem after the control window has already closed.

Q: What do security teams get wrong about the first security hire?

A: They often treat the first hire as a universal fixer instead of a coordinator of specialised capability. That expectation creates gaps in cryptography, cloud security, incident response, and application security. The better model is to define the security operating model first, then assign specialist coverage where the risk profile actually demands it.

Q: How can teams use AI without weakening security accountability?

A: Teams can use AI to make cloud and identity data easier to query, but they should keep ownership of interpretation, escalation, and remediation with named security leads. AI should reduce the time it takes to find evidence, not blur who decides what that evidence means. That distinction preserves accountability while improving operational speed.


Technical breakdown

Why the first security hire becomes a governance bottleneck

A startup security function is often framed as a staffing problem, but the underlying issue is operating model design. One person can coordinate risk, but cannot hold deep expertise in cryptography, Kubernetes, cloud telemetry, incident response, and application security at once. That creates a governance bottleneck where the company confuses coverage with capability. In practice, the team ends up reacting to surfaced issues instead of shaping the identity, cloud, and engineering controls that determine whether those issues appear at all. The article's strongest insight is that security maturity depends on specialist access, not just headcount.

Practical implication: build a security operating model that can pull in specialist expertise on demand instead of expecting a single generalist to cover every control domain.

How embedded security changes architectural risk

Embedded security works because it intervenes before identity and application decisions harden into architecture. The example in the article is instructive: a choice made early to avoid user-generated content permanently changed the cross-site scripting risk profile. That is the difference between tactical bug-fixing and structural risk reduction. For IAM and NHI teams, the same principle applies to service account design, token scope, and trust boundaries. If governance shows up after deployment, it mostly sees the consequences. If it shows up during design, it can prevent entire classes of identity exposure.

Practical implication: include security input at design reviews for identity boundaries, token use, and application trust models before implementation choices become expensive to unwind.

AI is lowering the barrier to security data access

The article also shows how AI changes security operations by making internal telemetry easier to query. Historically, teams relied on specialist knowledge and custom programs to interrogate cloud resources, GitHub, Okta, and related metadata. Natural-language querying changes that access pattern, but it does not remove the need for security judgement. It broadens who can ask questions of the data, which is useful, yet it also raises expectations that the team can detect misconfiguration and exposure faster. The operational risk shifts from data access scarcity to decision quality and response speed.

Practical implication: treat AI-assisted security querying as an accelerator for investigation and review, not as a substitute for governance expertise or policy ownership.


Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Startup security fails when it is treated as a single-person function. The article describes a market reality that many startups still understate: one generalist cannot simultaneously own application security, cloud security, incident response, and identity governance. That is not a hiring failure so much as a control design failure. Security coverage needs to be modular, because the risk domains are modular, and the practitioner conclusion is simple: staffing models must match the shape of the threat surface, not the org chart.

Architecture decisions create longer-lived identity risk than most vulnerability backlogs. The cross-site scripting example matters because it shows how an early application choice can lock in exposure for years. That is a stronger lesson for IAM and NHI programmes than any short-term remediation metric. Once identity boundaries, token use, or data paths are baked into architecture, later reviews mostly document the debt instead of eliminating it. The practitioner conclusion is that governance earns its leverage before release, not after incident tickets start arriving.

Fractional security is a control model, not a staffing compromise. The article's embedded specialist model shows that deep expertise can be organised as an ongoing governance layer rather than a permanent hire. That is especially relevant for startups that cannot justify full-time specialists across cryptography, cloud telemetry, and identity controls. The key implication is that capability coverage matters more than employee count, and security maturity should be measured by access to the right expertise at the right moment.

AI-assisted security operations change who can interrogate identity and cloud evidence. The article's natural-language querying example suggests that security teams will increasingly democratise access to telemetry. That widens participation, but it also creates a stronger need for clear policy ownership and interpretation discipline. The practitioner conclusion is that AI should compress investigation time, not dilute accountability for the decisions that follow.

From our research:

  • The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
  • Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why control confidence often outpaces real operational discipline.
  • For a deeper breach-focused view, the 52 NHI Breaches Analysis shows how weak governance assumptions become persistent exposure.

What this signals

The practical signal for readers is that security maturity will increasingly be measured by how quickly expert judgment can be brought to the point of design, not by whether a first hire exists. Fractional security models make that possible for smaller organisations, but only if they are tied to clear decision rights and architecture review gates.

With 32.4% of security budgets now going to secrets management and code security in our research on appsec, the pressure to rationalise where expertise sits is not temporary. Startups that treat security as a shared operating capability will scale more cleanly than those that over-rely on a single generalist role.

Embedded security capability: the emerging model is less about headcount and more about durable access to specialist judgement across application, cloud, and identity risk. That matters because the next governance gap is not a missing tool, but a delay between design decisions and informed security review.


For practitioners

  • Map security work to specialist domains Break the first-year security roadmap into application security, cloud security, incident response, secrets handling, and identity governance. Use that map to identify which capabilities require ongoing coverage and which can be delivered through embedded advisory support.
  • Move security into design reviews earlier Require security sign-off for architecture decisions that affect identity boundaries, token scope, data paths, and user interaction models. The goal is to stop hardening risky patterns before they become expensive programme debt.
  • Create an on-demand specialist bench Assemble external or fractional expertise for cryptography, Kubernetes, cloud telemetry, and incident response so the team can escalate into depth when needed. Document the trigger points that route work to those specialists.
  • Use AI to widen telemetry access carefully Let engineers query cloud and identity metadata in natural language, but pair that access with review rules and clear ownership for findings that affect production risk. Speed should improve investigation, not replace governance.

Key takeaways

  • The article argues that startup security breaks down when one person is expected to cover too many specialised domains at once.
  • Its strongest evidence is architectural: decisions made early can lock in years of avoidable identity and application risk.
  • The practical answer is to build ongoing access to specialist security judgement before deployment, not after incidents expose the gap.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0GV.RM-01The article is about building repeatable security governance, not a one-off hire.
NIST Zero Trust (SP 800-207)PR.AC-4Identity boundaries and access decisions are central to the article's architecture theme.
OWASP Non-Human Identity Top 10NHI-03Secrets handling and identity governance are part of the article's security coverage model.

Treat secret exposure and lifecycle control as recurring governance work, not ad hoc cleanup.


Key terms

  • Fractional Security: A security operating model where specialist expertise is provided on an ongoing part-time or embedded basis rather than through a single full-time generalist hire. It works best when the organisation needs depth across several domains but cannot yet support separate internal specialists.
  • Security Architecture Debt: The long-lived risk created when early design choices lock in weaker controls, trust boundaries, or identity patterns. It is harder to remove than a typical vulnerability because the problem sits in how the system is built, not just in a single configuration or code defect.
  • Identity Governance: The set of controls and decision processes that determine who or what can access systems, data, and actions, and under what conditions. In practice it covers provisioning, privilege scope, review, and lifecycle management across human, non-human, and autonomous identities.

Deepen your knowledge

Security coverage, architecture review, and identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a startup security model that needs to scale without a unicorn hire, it is worth exploring.

This post draws on content published by WorkOS: Latacora is security for startups without the unicorn hire. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-01-14.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org