Notifications
Clear all
Topic starter
07/06/2026 8:24 pm
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.
NHIMG editorial — based on content published by WorkOS: Latacora is security for startups without the unicorn hire
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map security work to specialist domains Break the first-year security roadmap into application security, cloud security, incident response, secrets handling, and identity governance.
- 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.
- 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.
What's in the full article
WorkOS's full interview covers the operational detail this post intentionally leaves for the source:
- The direct conversation with Laurens Van Houtven about how Latacora structures long-term embedded security work
- Examples of how the team uses historical cloud-resource graphs across AWS, GitHub, and Okta in practice
- The practical differences between AI for security work, AI in products, and AI used by attackers
- The source article's additional context on how the role of email and phishing defence has changed over time
👉 Read WorkOS's interview on Latacora and startup security without a unicorn hire →
Startups without a first security hire: what changes with fractional security?
Explore further
07/06/2026 10:17 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Latacora shows why startups need embedded security, not unicorns
