Identity and access management (IAM) for startups and fintechs with a lean team

Why internal IAM is different from end-user anti-fraud

Protecting the customer's account against account takeover is a fraud problem in the product. Corporate IAM is another domain: it deals with how your employees, contractors, and internal systems access repositories, production infrastructure, cloud consoles, data tools, and dozens of SaaS apps. The attacker here is not after a user's account; they are after an engineer's credential or a service key that opens the door to the entire environment.

In growing startups and fintechs, risk accumulates silently. With every hire, tool integration, and deployment, new identities and permissions appear with no clear owner. Without an identity plan, the company ends up with reused passwords, optional MFA, former employees with active tokens, and production keys in versioned .env files.

CIS Controls v8 places account management (Control 5) and access control management (Control 6) among the foundations of security hygiene precisely because most incidents start with a compromised or over-privileged identity. The good news: the baseline that follows is implementable by a small team, largely through configuration and automation rather than headcount.

SSO and federation: centralizing authentication in OIDC and SAML

Single Sign-On with an identity provider (IdP) is the first piece. Instead of each SaaS storing its own password, the IdP authenticates the user and issues an identity assertion to the application. This creates a single point where you enforce MFA, session policy, access conditions, and, crucially, the immediate shutdown of an account.

The two federation protocols that matter are SAML 2.0 and OpenID Connect (OIDC), the latter built on OAuth 2.0. SAML, XML-based, still dominates legacy B2B integrations and many enterprise SaaS plans. OIDC, based on JSON and JWT, is the standard for modern applications, APIs, and mobile. One distinction that saves confusion: OAuth 2.0 is about authorization (delegating access to a resource), while OIDC adds the authentication layer (proving who the user is). Do not use plain OAuth as proof of login.

Implementation watch-outs: prefer the Authorization Code flow with PKCE for public applications and SPAs; validate the signature, issuer (iss), audience (aud), and expiration of every token; never accept tokens without checking the IdP's key. In SAML, validate the assertion signature and restrict the Audience and validity window, avoiding replay and assertion-injection attacks.

Watch the cost of federation. Several vendors charge for SSO only in expensive tiers — the so-called 'SSO tax'. Even so, standardizing federation where possible and isolating the rest behind a corporate password manager with MFA is better than leaving authentications scattered around.

Decripte as an identity and access partner

Designing IAM with a lean team is largely an architectural decision: which IdP, how to model roles, how to automate the lifecycle, and how to prove compliance to customers and auditors. Decripte works on the preventive security of this layer — IdP configuration review, MFA policy, RBAC and least-privilege modeling, and the design of joiner-mover-leaver flows — so the baseline gets off paper without slowing the product down.

We also cover continuous operation: monitoring identity events (anomalous logins, privilege escalation, account and key creation), support for periodic access reviews, and preparation for the compliance requirements that enterprise customers, partners, and LGPD demand of fintechs. Start with our free plan and grow the identity program as the team and controls mature.

Phishing-resistant MFA, RBAC, and least privilege

Not all MFA is equal. NIST SP 800-63B classifies authentication assurance levels (AAL). SMS and app-based OTP (TOTP) raise the bar against leaked passwords, but they fall to real-time phishing, in which the user types the code into a fake page that relays it to the real service, and to SIM swap. Phishing-resistant authenticators — passkeys and security keys based on FIDO2/WebAuthn — bind the credential to the origin (domain) cryptographically, so a fake page cannot reuse the proof. Prioritize passkeys for everyone, and require hardware keys for administrators and production access.

On privileges: least privilege means granting the minimum necessary for the shortest window of time. RBAC (role-based access control) operationalizes this — you define roles (e.g., backend engineer, support analyst, finance) with sets of permissions, and you assign people to roles instead of granting individual permissions. This makes access auditable and offboarding predictable.

For high-impact resources — production, the customer database, the cloud console — go beyond the static role with just-in-time access: the permission is elevated on demand, with approval and automatic expiration, leaving a trail of who accessed what and why. Avoid accounts with permanent administrative privilege; separate the day-to-day account from the administrative one and protect the latter with the strongest authentication available.

Lifecycle (joiner-mover-leaver), production, and secrets

The identity lifecycle has three moments. Joiner: on arrival, the person receives access derived from their role, automated from the HR system or the directory, without scattered manual requests. Mover: when changing roles, old access is revoked to the same degree that new access is granted — avoiding the accumulation of privileges (privilege creep) is the central point here. Leaver: on departure, all access is cut immediately, including tokens, API keys, and active sessions.

A poorly executed leaver is the most common failure in growing companies and the most exploited: orphan accounts and forgotten tokens become an entry point. SCIM (System for Cross-domain Identity Management) is the protocol that lets the IdP provision and deprovision accounts in SaaS automatically; where SCIM exists, use it, and where it does not, keep an auditable offboarding checklist.

Production access and secrets deserve their own treatment. Credentials — API keys, tokens, certificates, connection strings — belong in a secrets vault, not in code, images, or cleartext environment variables. Establish rotation, minimal scope per secret, and auditing of vault access. Service accounts are non-human identities and demand the same rigor: a defined owner, minimal scope, no long-lived credentials when there is an alternative (use federated workload identities, such as OIDC for CI/CD instead of static keys). Inventory and review these identities alongside the human ones.

Access reviews and metrics for a lean program

An unreviewed control decays. Run an access review (access recertification) at least quarterly for sensitive access: the owner of each system confirms who should keep access and at what level, and whatever remains is revoked. This satisfies both the hygiene of CIS Control 6 and the compliance requirements that enterprise customers and LGPD bring to fintechs.

Measure a few things, but measure them. SSO coverage (the percentage of applications behind the IdP), phishing-resistant MFA coverage, the number of accounts with permanent administrative privilege, the time between departure and full revocation, and the number of ownerless service accounts. These metrics show the real risk surface and where the small team should invest its next effort.

A pragmatic sequence: start with the IdP and universal MFA, bring critical applications into SSO, model the first roles, automate the leaver, and protect production and secrets. Do not chase full maturity at once; each step already reduces the attack surface. Document the decisions so the next hire inherits a system, not a collection of exceptions.

Practical checklist

1. 1

   1. Choose and configure an IdP

   Select an identity provider and make it the single point of login. Define session policy, access conditions, and centralized logging of authentication events.

2. 2

   2. Require phishing-resistant MFA

   Enable passkeys/FIDO2 (WebAuthn) for everyone and hardware keys for administrators and production access, aligned with the AAL2/AAL3 level of NIST SP 800-63B.

3. 3

   3. Federate the critical applications

   Connect SaaS and internal tools via OIDC (Authorization Code with PKCE) or SAML 2.0. Validate the signature, issuer, audience, and expiration of tokens and assertions.

4. 4

   4. Model roles with RBAC and least privilege

   Define roles by function with the minimum set of permissions. Assign people to roles, not individual permissions, and eliminate permanent administrative privilege.

5. 5

   5. Automate joiner-mover-leaver

   Provision and deprovision via SCIM from the directory/HR. On departure, cut accounts, tokens, API keys, and sessions immediately; keep an auditable checklist.

6. 6

   6. Protect production and secrets

   Use just-in-time access with approval and expiration for production. Store secrets in a vault with rotation and minimal scope; prefer federated workload identities over static keys.

7. 7

   7. Review access and measure

   Perform quarterly recertification of sensitive access and track SSO/MFA coverage, permanent administrative accounts, and revocation time at offboarding.

Frequently asked questions