Most designers think cybersecurity is someone else's problem. The backend team. The DevOps guy. The security consultant who shows up once a year with a PDF full of red flags.

I used to think the same.

Then we started working with Deltia AI on their user flows, onboarding, and account management. And the security requirements that came with their compliance work completely changed how I think about designing sign up flows, user management, and session handling.

Not because security made things harder. Because it made things better.

Bruce Schneier once said: "Security is a process, not a product." And the thing is, that applies to design too. When you treat security as a constraint, not a blocker, your user flows actually get cleaner.

This is the story of how that happened, what we changed, and why I now work with a pentest partner called Candela to pressure-test every flow we design.

The problem: Most SaaS sign up flows are designed for conversion, not trust

Here's what I see all the time with early-stage AI startups. The founder builds a product, ships a landing page, and the entire sign up flow is optimized for one thing: getting the user in as fast as possible.

Minimal fields. No email verification. Weak password requirements (or none). No session management. No role-based access. No audit trail.

And it works. For a while.

Then the startup tries to close an enterprise deal. Or go through SOC 2. Or sell into a regulated market in Europe where ISO 27001 is expected. And suddenly the product needs session timeouts, MFA, proper user management, password policies, and a dozen other things that the design never accounted for.

So what happens? The engineering team bolts security on top of a flow that was never designed for it. The UX becomes a mess. Users get frustrated. Support tickets pile up.

To me, that's a design problem, not a security problem.

Why security constraints actually improve UX

Here's what most founders don't realize: the things that compliance frameworks like SOC 2 and ISO 27001 require you to build are the same things that make users trust your product.

Think about it:

Email verification isn't just a security checkbox. It reduces fake accounts, improves your user data quality, and makes your onboarding emails actually reach real people.

Password strength requirements done right (showing a checklist, not a cryptic error message after submission) reduce support tickets and failed logins.

Session management (automatic timeouts, device tracking) gives users a sense that you take their data seriously. Enterprise buyers specifically look for this.

Role-based access control means teams can actually use your product without the admin worrying about who can delete what. That's not security overhead. That's good product design.

MFA that's designed well (triggered contextually, not on every single login) actually increases adoption. There's research showing that when you make MFA frictionless, adoption rates can go up significantly.

The constraint forces you to think about the user's mental model. Where are they in the flow? What's the risk level of this action? Do they need to re-authenticate here, or is that overkill?

That's UX thinking. It just happens to also be security thinking.

What we changed at Deltia AI

When we started designing Deltia AI's user flows, the team was already working toward compliance certifications. So instead of designing the "ideal" flow first and patching security later, we did it the other way around.

We started with the constraints.

1. Sign up flow: Security-first, but still fast

We kept the sign up form minimal (email + password). But we added:

• A real-time password strength indicator that shows requirements as you type, not after you submit

• Email verification as a required step before accessing the product, but with a clear progress indicator so users know where they are

• SSO options for enterprise users right from the start (not hidden in settings somewhere)

The result? The sign up flow takes maybe 10 seconds longer than a "just enter your email" approach. But the user quality is dramatically better. Fewer fake accounts. Fewer support tickets about lost passwords. And enterprise prospects see a product that looks ready for them.

2. User management: Roles that make sense

Instead of the typical "admin / member" binary, we designed a role system that maps to how teams actually work:

• Owner: Can do everything, including delete the workspace

• Admin: Can manage users and settings, but can't delete the workspace

• Member: Can use the product, can't change settings

• Viewer: Read-only access for stakeholders who just need to see results

Every role has clear permission boundaries. And the UI makes those boundaries visible. When a member tries to access admin settings, they don't get a confusing error. They see a clean explanation of what their role allows and who to contact for access.

That's a compliance requirement. But it's also just good UX.

3. Session handling: Invisible security

This is the one that surprised me the most. Good session handling is basically invisible to the user when it's designed well.

We implemented:

• Automatic session timeouts after inactivity (with a gentle warning before it happens)

• Device management so users can see where they're logged in and revoke sessions

• Re-authentication for high-risk actions (changing email, deleting data, inviting team members)

The re-authentication step is key. You don't ask users to re-enter their password for everything. Just for the actions where the damage of a compromised session would be high.

That's the design thinking part. The security team tells you what needs protection. The designer decides how it feels.

4. Audit trails that build confidence

Every action in the workspace gets logged. User invited. Role changed. Data exported. Settings modified.

We designed a simple activity log that admins can filter by user, action type, and date range. It's not a security dashboard buried in dev tools. It's a clean, readable timeline that any non-technical founder can understand.

Enterprise buyers love this. And from a compliance perspective, it's required for most frameworks.

How pentesting changed our design process

Here's where Candela comes in.

Candela is a penetration testing service that we started working with to validate the flows we design. And the thing is, working with pentesters taught me things about user flows that I never would have learned otherwise.

A pentest doesn't just find code vulnerabilities. It finds flow vulnerabilities.

For example:

Password reset flows are a common attack vector. If your reset flow doesn't rate-limit attempts, doesn't expire tokens quickly enough, or sends the user to a page that confirms whether an email exists in your system, that's a security risk. But it's also a design decision. You chose to show "No account found with this email" because it felt helpful to the user. A pentester will tell you that message just gave an attacker information they shouldn't have.

Invitation flows can be exploited if they don't expire or if the invite link gives full access before the user sets a password. We had to redesign how invitations work so the link leads to a password creation step, not directly into the app.

Session tokens that persist too long or don't rotate properly mean a stolen cookie gives an attacker ongoing access. The design implication? You need to think about when to show "You've been logged out" messages and make the re-login experience smooth, not punishing.

Working with Candela made me realize that every flow I design has a security surface. And the earlier I think about that surface, the cleaner the final design is.

As the saying goes: "Design is not just what it looks like and feels like. Design is how it works." That was Steve Jobs, and he was talking about exactly this. The invisible mechanics matter as much as the visible interface.

A practical framework: Security-aware UX design for SaaS

After going through this process with Deltia AI (and now applying it to other clients), I've landed on a simple framework for designing user flows that are both secure and usable.

Step 1: Map every user flow and label the risk level

Before you open Figma, list every flow in your product: sign up, login, password reset, invitation, role management, data export, account deletion, billing changes.

For each flow, ask: "What's the worst thing that could happen if this flow is exploited?" That gives you a risk level.

High-risk flows (account deletion, payment changes, data export) get extra friction. Low-risk flows (changing a profile photo, updating notification preferences) stay fast and simple.

Step 2: Design the security step as part of the flow, not as an interruption

This is where most products fail. They add security as a pop-up, a modal, an extra screen that feels like an afterthought.

Instead, design the security step as a natural part of the flow. Re-authentication? It's a step in the process, with clear context about why you're being asked. MFA setup? It's part of onboarding, not a nag screen that shows up three weeks later.

Step 3: Use progressive security

Not every user needs every security feature on day one. A solo founder testing your product doesn't need MFA. But when they add team members, that's the moment to introduce it.

Design security features to activate contextually:

• First team member added → suggest role setup

• First enterprise user signs up → prompt SSO configuration

• Sensitive data uploaded → recommend MFA

This way, security grows with the user instead of overwhelming them upfront.

Step 4: Test with a pentest

This is the step most startups skip. And I get it, pentesting sounds expensive and scary. But services like Candela make it accessible. You scope the test, they simulate real attacks against your flows, and you get a prioritized list of what to fix.

The findings always surprise me. Things that seemed fine from a UX perspective turn out to have security implications I didn't consider. And fixing them almost always makes the UX better, not worse.

The compliance angle: SOC 2 and ISO 27001 aren't just checkboxes

If you're an AI startup targeting enterprise customers, you're going to need compliance certifications sooner or later. SOC 2 is the standard in the US market. ISO 27001 carries more weight internationally, especially in Europe.

Both frameworks care deeply about how users access your system. Authentication, authorization, session management, audit logging. All of it.

The startups that design for compliance from day one save themselves months of painful retrofitting. The ones that don't end up with a Frankenstein product where security is bolted onto a flow that was never meant to support it.

To me, the best approach is simple: treat compliance requirements as a design brief. They tell you what the product needs to do. Your job as a designer is to make it feel effortless.

What this means for your startup

If you're building a SaaS product right now, especially in AI, here's what I'd tell you:

Don't separate design from security. Every user flow has a security surface. The sign up flow, the onboarding, the settings page, the invitation flow. Design them together from the start.

Get a pentest before you scale. A penetration test on your user flows will catch things that no amount of internal review will find. Work with someone like Candela who gives you prioritized, actionable findings.

Use compliance as a design constraint, not a roadblock. SOC 2, ISO 27001, GDPR, they all tell you what good looks like. Use that as your design brief.

Think about the enterprise buyer from day one. Even if your first users are solo founders, the ones who'll pay you real money are teams. And teams expect proper user management, session handling, and audit trails.

The startups that get this right don't just pass security audits. They build products that users genuinely trust. And trust is the one thing you can't bolt on after the fact.