Why authentik fits SaaS and technology companies running their own identity
authentik fits a SaaS or software team that wants its identity provider inside its own cloud account, with OIDC, SAML and LDAP providers it operates itself. The typical situation is familiar: a growing set of internal tools, a customer base that logs in every day, and a SOC 2 examination approaching. In that position, identity stops being a convenience and becomes a system the team must explain, control and evidence. Self-hosting changes three things. Identity ownership moves to your team, so configuration, the user store and the audit trail sit with people you employ. Data location is your choice, because the server, worker and PostgreSQL database run in the cloud accounts or data centers you select. The build-versus-buy question also changes, since you weigh the cost of running a directory-grade service against the subscription cost of a hosted identity product.
The cost discussion depends on licensing. Most of the authentik code is under the MIT license, so the core can be deployed, modified and run without a license fee. The code in the authentik/enterprise/ directory is under a separate enterprise license defined in that directory, and the features that depend on it are the ones to price carefully. The pricing page lists Enterprise-only items that SaaS teams often ask about, including Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, password history and enhanced audit logging. Before you decide, confirm with authentik which of these you need, check the current pricing terms and map each one to a specific internal tool or control. Ask whether a feature is needed for launch or only for a later audit window.
Build-versus-buy also includes effort that does not appear on any price list: a SOC 2 readiness review, deployment hardening, upgrade planning across releases, backup and restore testing, and on-call coverage for sign-in outages affecting customers. Those costs are one-time for the initial build and recurring for operations, and they grow with the number of applications and external users. A written scope from a partner such as DeployOpen should separate the one-time build from the recurring support, name which enterprise features are included, and state who owns each operational task after handover.
Requirements that shape a SaaS authentik build
This table compares the requirements that most affect a SaaS identity build: workforce SSO, customer identities, per-domain branding, SOC 2 access evidence and EU switching duties. Read each row for the source it draws on and the decision it forces, then confirm the open points with your auditor and counsel before scoping the work.
| Requirement | What the source asks or enables | What it means for the build |
|---|---|---|
| Workforce SSO across SaaS and internal tools | authentik documents OAuth2/OIDC, SAML and LDAP provider types (authentik providers documentation) | Map each SaaS app and internal tool to a provider type first. Apps that only accept LDAP or need a reverse proxy change the sizing and the access model. |
| Google Workspace or Entra ID as a directory | These integrations are listed as Enterprise-only on the authentik pricing page | If your staff sign in through Google Workspace or Entra ID, price the Enterprise tier against your user count before choosing the architecture. |
| External customer users | Enterprise lists $5 per user per month billed annually plus $0.02 per external user per month (authentik pricing page) | Model customer identities separately from staff. External user volume, not staff count, may drive your recurring license cost. Confirm current terms with the vendor. |
| Brands per domain | authentik documents flows and policies that include branding per domain (authentik flows and policies, as a documented capability area) | Plan one custom domain or brand per customer-facing product. Confirm with the vendor how many domains and brandings your chosen edition supports. |
| SOC 2 access evidence (CC6) | AICPA 2017 Trust Services Criteria CC6 covers logical and physical access controls, which assessors test for design and, in Type 2, operating effectiveness | Export evidence of who has access, when it was granted and removed. Enhanced audit logging is Enterprise-only, so check whether the Open Source tier meets your log retention needs. |
| Privileged access and mTLS | Privileged access management and mTLS client certificate authentication are listed as Enterprise features (authentik pricing page) | Decide early whether admin access to production tools needs these controls. Building them yourself is an engineering cost that must be weighed against the license. |
| Data location and switching (EU customers) | EU Data Act Article 23 requires providers to let customers switch to another provider or to on-premises infrastructure. Article 25 sets the switching terms (EU Data Act) | Design exports and deployment portability into the platform from the start. Confirm with counsel whether authentik-hosted customer data falls under this regulation for your service. |
| Licensing of code you modify | Most code is under MIT, but the authentik/enterprise/ directory uses a separate enterprise license (authentik LICENSE on GitHub) | If you build on Enterprise code, check the enterprise license terms before distributing modified software to customers. Confirm with your legal team. |
Which authentik providers and settings matter for product teams
Workforce administrators decide which employees can reach which SaaS applications and internal tools. In authentik, this work centers on application records bound to providers, plus the directory and provisioning links that keep accounts aligned with the people who should have them. The provider list includes OAuth2/OIDC, SAML, LDAP, proxy, SCIM and the Google Workspace and Entra ID integrations, so the first decision is which of these your internal estate already uses.
- OAuth2/OIDC and SAML providers: Most modern SaaS tools accept one or both. Confirm each vendor's supported protocol and required claims before creating the provider.
- SCIM for provisioning: Provisioning creates, updates and removes accounts in target applications. Offboarding evidence depends on this working, so test deprovisioning, not only sign-in.
- Google Workspace and Entra ID integrations: These are Enterprise features on the pricing page. If your workforce identity lives in one of them, factor the license into the comparison with building equivalent logic yourself.
- Group-based access: Map groups to applications so that access follows role changes without manual edits per tool.
- MFA enforcement in flows: Require second factors for administrative applications through the authentication flow, not per application.
Before go-live, check that every application has a named owner, that deprovisioning removes access in each SaaS tool, and that sign-in events are retained for your review cycle.
Product and customer identity owners care about how external users sign in to the application they buy or build. Here the relevant settings are the OAuth2/OIDC or SAML provider configuration for each product, the external user pricing on the Enterprise tier, and the flows that handle enrollment, invitation and recovery. Customer-facing sign-in is also where branding matters most, because each product domain may need its own look and login path.
- Client registration per product: Each product or environment gets its own OAuth2/OIDC client with specific redirect URIs, scopes and signing settings. Keep these in version control so changes are reviewed.
- External user model: The pricing page lists a per-external-user monthly charge on the Enterprise edition. Ask for the expected count of active external users, since that figure drives the recurring license cost.
- Per-domain branding through flows: Flows and their bindings let you present different login pages and enrollment steps for different domains or applications. Confirm the exact binding behavior in the current release notes before designing around it.
- Self-service recovery: Recovery flows reduce support load but need rate limits and verification steps you can explain to your security team.
- Customer-to-internal separation: Keep customer users in a distinct population or group so that an internal policy change does not affect them, and the reverse.
Before launch, run a sign-in test for each product domain, including recovery and invitation paths, and record which flow each domain uses.
Platform engineers own the components that keep authentik running. A standard deployment has a server container, which runs core with an embedded outpost, a worker container for background tasks, and PostgreSQL, which stores all configuration and data except uploaded files. Since the 2025.10 release, Redis is no longer used, so caching, tasks, sessions and WebSocket functions run on PostgreSQL, and the release notes warn of roughly 50% more PostgreSQL connections after upgrading.
- Server and worker containers: Size and scale them separately. Background work such as provisioning runs in the worker, so a slow worker can delay account changes even when sign-in works.
- PostgreSQL as the single data store: Plan backups, connection limits and major version upgrades around it. The Compose guide suits test and small production setups, while the Kubernetes guide recommends a separately managed PostgreSQL for production.
- Outposts for protected applications: The embedded outpost handles proxy providers. Separate outposts may be needed for network segments, so confirm placement before designing the proxy layout.
- Supported versions: The security policy lists 2026.5.x and 2026.8.x as receiving security fixes, and security releases are announced at least 24 hours in advance. Track this in your patch calendar.
- Configuration as code: Keep providers, flows and applications in declarative configuration so environments stay consistent.
Before production, confirm connection pool sizing against PostgreSQL limits and rehearse an upgrade in a non-production environment.
Enterprise features versus building them: what the cost comparison includes
authentik's Open Source edition is MIT-licensed, while the Enterprise features sit in a separate enterprise license. Each card below covers one Enterprise-only capability, what it would take to build yourself, and what to confirm before you compare the two.
Google Workspace and Entra ID integrations
These directory and provisioning connectors are listed as Enterprise-only on the pricing page. Building them yourself means writing and maintaining sync logic against two vendor APIs that change over time, then owning the user lifecycle, group mapping and error handling. Ask whether your team has the skills and on-call capacity to keep those connectors current. Confirm which provisioning direction and attributes your SaaS tenants need before estimating either path.
mTLS client certificate authentication
Mutual TLS lets clients authenticate with certificates, which matters for B2B API partners and some admin paths. Building it means deciding certificate issuance, revocation checking, trust chain handling and how certificate identity maps to an authentik user. Recurring work includes rotating the CA material and testing renewals before expiry. Ask your team who owns the PKI and whether an existing internal CA can be reused.
Privileged access management
Privileged access covers approval-gated, time-limited elevation for administrators and production access. Building it requires request workflows, approver routing, session expiry and an audit trail that auditors can read. The main recurring cost is keeping approval policies aligned with your change process as teams and roles change. Confirm whether you need this for production infrastructure only or for all internal tools, because scope drives the build.
Password history
Password history stops users from reusing recent passwords for local accounts. It sounds small, but it touches the password change flow, storage of previous password hashes and the policy checks that run at each change. Building it means hardening that storage and testing edge cases such as admin resets and recovery. Check whether your users sign in mainly through federated providers, since the feature only helps accounts that hold a local password.
Enhanced audit logging
Enhanced audit logging is listed as Enterprise-only and matters because SOC 2 access evidence depends on who did what and when. Building an equivalent means defining event schemas, shipping logs off the host, protecting them from edits and keeping retention aligned with your evidence period. Ask which events your auditors will sample and whether the standard logs already cover them before you pay for the extra logging.
How a SaaS team rolls out authentik in phases
The sequence moves from an inventory of applications and user populations to a deployment, source connections, staged app migrations, customer-facing flows and an ongoing evidence and operations routine. Each phase closes with a check that the next one can rely on.
Inventory applications and user populations
Before any installation, list every application that will sign in through authentik, the protocol each one supports (OAuth2/OIDC, SAML, LDAP, proxy or SCIM provisioning), and the user groups that need access to each. Separate workforce users from external customers, since they usually need different sign-in flows, branding and lifecycle rules. Confirm which SaaS applications need Enterprise-only integrations, such as Google Workspace or Microsoft Entra ID, so licensing is settled before the build. The phase is done when the team has a signed-off inventory with an owner and a protocol for each application.
Choose the deployment model and database
Decide between Docker Compose and Kubernetes based on the team's operating model. authentik's Docker Compose guide positions Compose for test setups and small-scale production, and calls for a host with at least 2 CPU cores and 2 GB of RAM as a starting point. The Kubernetes guide installs with Helm but notes that the bundled PostgreSQL is for demonstration and testing, so production needs a separately managed PostgreSQL service. Ask the platform team to confirm backup, high availability and connection limits for that database before go-live. The phase is done when the target architecture and database ownership are written down.
Stand up the server, worker and database
Install authentik into the chosen environment, which runs a server container (core with an embedded outpost), a worker container for background tasks and PostgreSQL that stores configuration and data. Put the admin interface behind TLS and restrict admin access to named staff. Because the 2025.10 release moved caching, tasks, sessions and WebSocket functions to PostgreSQL, size database connection limits with that load in mind. The phase is done when a test sign-in succeeds, background tasks run on the worker, and backups of the database have been restored once in a non-production copy.
Connect identity sources and directories
Connect the upstream sources that hold your workforce identities, such as an existing directory, Google Workspace or Entra ID, and confirm which of these need the Enterprise edition. Map group membership and attributes that drive application access, and decide which accounts are authoritative in each source. Test that a disabled upstream account can no longer sign in to authentik. The phase is done when a representative set of test users authenticates through each source and group mapping matches the inventory from the first step.
Migrate SaaS applications in waves
Move applications in small waves rather than all at once. Start with a low-risk internal tool, then move workforce SaaS applications such as those used for email, chat, source control and support, and add SCIM provisioning where the application supports it. For each application, keep the previous login method available until a rollback has been tested, and record the protocol settings and redirect URIs used. The phase is done when each wave has a recorded test, named owners for the application and a documented fallback.
Add external customer flows and branding
Configure the sign-in experience for external customers separately from workforce access. Set up enrollment, password recovery and any invitation flows that your product requires, and apply branding per domain or per application so customers see your product and not the identity layer. Review which policies, such as password rules or GeoIP checks, apply to external users, and confirm the per-user pricing for external accounts in the current price list before you model cost. The phase is done when a customer test account completes enrollment, sign-in and recovery on each branded domain.
Collect access evidence for SOC 2
Set up recurring exports of who had access to which application, when access was granted or removed, and which administrators changed policies or sources. Enable the enhanced audit logging available in the Enterprise edition if your audit scope needs it, and forward logs to the system your security team already reviews. Tie each export to a control owner and a review cadence, because a SOC 2 examination tests whether controls operated over a period, not only whether they exist. Ask your auditor which evidence formats they accept. The phase is done when a sample access review can be produced from the exported records within the review window.
Run upgrades and operations on a fixed routine
Set an operating routine for upgrades, monitoring and backups. authentik's security policy lists 2026.5.x and 2026.8.x as supported versions receiving security fixes, and the project announces security releases at least 24 hours in advance, so subscribe to release notices and plan a window that can absorb a short-notice patch. Upgrades must follow the sequential path documented for each release, so do not skip versions. Track PostgreSQL capacity after each upgrade. The phase is done when the team has a tested upgrade in a staging copy, an alerting rule for failed sign-ins and worker errors, and a named owner for each recurring task.
What SOC 2 access evidence authentik can support
An identity platform can produce much of the access evidence a SOC 2 examination asks for, but it cannot make a SOC 2 report. SOC 2 examinations assess controls against the AICPA 2017 Trust Services Criteria, which cover five categories: security, availability, processing integrity, confidentiality and privacy. The security common criteria, CC1 to CC9, apply to every SOC 2, and the logical access criteria in CC6 are where authentik's configuration and logs matter most. The other four categories are added only when they are in scope, so decide that early because it determines what the auditor will test.
A Type 1 report describes your system and assesses whether controls are suitably designed as of a date. A Type 2 report adds an opinion on whether those controls operated effectively over a period. For authentik, Type 1 needs documented design: which applications sit behind authentik, who approves access, how MFA is enforced through flows and policies, and how the authentik admin roles are assigned. Type 2 needs repeatable evidence over the period: provisioning and deprovisioning records from directory sync or SCIM, MFA enforcement results, admin role changes and audit log exports, with samples the auditor can trace. Confirm with your auditor which evidence format and sampling approach they expect before you configure logging. DeployOpen prepares systems, controls and evidence for the examination, but the independent auditor issues the report.
The examination is an assertion-based engagement under AT-C section 205, which requires the service auditor to obtain written representations from management, so your leadership must be prepared to sign off on the system description and control statements. Plan for that. Also note that a SOC 2 report is generally restricted in use, unlike a SOC 3 report, which is a general use report with less detail. Your customers can usually read your SOC 2 only under agreement, so if you need a public trust statement, decide whether a SOC 3 fits, and keep authentik's access evidence within the examination's defined system boundary.
Questions SaaS teams ask before hiring help with authentik
What drives the cost of an authentik implementation?
The scope written into the engagement drives most of the cost, not the software itself. The Open Source edition is free to download and run, so the spend is labor, infrastructure and any licenses you choose to buy. Scope drivers include the number of providers (OAuth2/OIDC, SAML, LDAP, SCIM and others), the number of applications to onboard, custom flows and policies, the number of brands or domains, and how many external user populations need separate enrollment and recovery paths. Recurring costs include hosting, PostgreSQL, upgrades and any Enterprise subscription. The authentik pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month. Ask any quote to separate one-time build work from recurring support, and to state which Enterprise features it assumes.
Can our engineers build and run authentik without outside help?
Yes, many teams do, and the open-source code is licensed under MIT for most of the repository. The work that tends to need the most experience is the first design: how users, groups and applications map to providers, how flows and policies handle enrollment and recovery, and how the deployment is hardened. Your team should check whether it has people who can own a Docker Compose or Helm deployment, a managed PostgreSQL instance, reverse proxy configuration and on-call for identity failures. Identity is a shared dependency, so a lockout affects every application. A useful test is whether two engineers can restore the service from backups and explain each provider's configuration without the original builder present.
How long does an authentik rollout take, and what changes the timeline?
No duration was supplied for this work, so treat any timeline in a proposal as an estimate to test, not a fixed figure. The largest drivers are the number of applications, whether they support OIDC or SAML natively or need the proxy outpost, the state of your existing directory and user data, and how many identity sources must be federated during the transition. Deployment itself is comparatively short. Testing, cutover, and moving users from another identity provider usually take longer. Ask the provider to break the timeline into phases with acceptance criteria, and to name which applications are in the first cutover wave.
Do we need Enterprise for Google Workspace or Entra ID integration?
Yes. According to the authentik pricing page, the Google Workspace and Microsoft Entra ID integrations are Enterprise-only features, alongside mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support for subscriptions over $1k. Open Source provides community support through Discord only. If your SaaS tools are already tied to Google or Microsoft directories, confirm the exact provider types you need against the authentik providers documentation, and confirm the license terms for code in the authentik/enterprise/ directory, which is governed by a separate enterprise license. Include Enterprise subscription cost in the comparison with building equivalent features yourself.
How do we produce SOC 2 access evidence from authentik?
authentik produces the raw records, and your organization produces the evidence an auditor will test. A SOC 2 examination uses the AICPA 2017 Trust Services Criteria, and the common criteria CC6 series covers logical access, which is where identity controls usually sit. Plan for access review exports, provisioning and deprovisioning logs, MFA enforcement settings, and change records for providers and policies. Enhanced audit logging is an Enterprise feature, so confirm whether your audit trail needs it. Forward logs to a store your auditors can query. A SOC 2 report is issued by an independent CPA firm, and DeployOpen prepares systems, controls and evidence for that assessment but does not issue reports.
What does an authentik upgrade involve for our team?
An upgrade is a planned change to the server, worker and any outposts, and it usually includes database work. authentik publishes versions named by year and month, and its security policy lists 2026.5.x and 2026.8.x as the versions receiving security fixes. The project announces security releases at least 24 hours in advance, which sets a minimum window to respond but not a planning schedule. Read the release notes for each version between your current release and the target, because breaking changes are documented per release. The 2025.10 notes also state that authentik moved caching, tasks and sessions to PostgreSQL and warn of roughly 50% more PostgreSQL connections after upgrading, so check connection limits and pooling first. Ask any retainer to define who runs staging tests and rollback.
What should we confirm before asking for a quote?
Start with a written list of applications, user populations (workforce, customers and partners), the protocols each one needs and the Enterprise features you expect to use. Then confirm where the platform will run, which PostgreSQL service will host the data, and what backup and recovery targets your team expects. Ask whether the quote is fixed-scope with deliverables and timelines agreed in writing before work starts, and whether ongoing support is priced separately as a retainer. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask the provider to state which parts of the work are one-time and which recur, and who is responsible for Enterprise licensing.
Compliance considerations beyond SOC 2 for software vendors
Start by deciding which regulatory roles your company holds, because identity obligations follow those roles. NIS2 Annex I treats cloud computing providers as digital infrastructure and managed service providers as ICT service management, both high-criticality sectors. A SaaS vendor that runs a hosted authentik tenant for customers, or operates identity services for other organizations, should ask counsel whether it is in scope and under which category. The Cyber Resilience Act is a separate test. It applies to products with digital elements, including software, from 11 December 2027, and its Article 14 reporting duties have applied since 11 September 2026 to in-scope products whenever they are placed on the market. If you ship a product that embeds an authentik-based login component, record which product versions include it, which authentik release line they track, and who receives vulnerability reports.
Identity data is personal data, so the processor terms matter as much as the technical design. Where you run authentik for customers' workforce or external users, GDPR Article 28(3) expects your contract to limit processing to documented instructions, including for transfers, and to require the security measures of Article 32. Name where the PostgreSQL database, worker logs and any forwarded logs are stored, because authentik keeps configuration and data there apart from uploaded files. The EU Data Act adds a switching requirement. Since 12 September 2025, data processing service providers must let customers move to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period. From 12 January 2027, switching charges may not be imposed. Confirm with counsel whether your identity service falls within that definition and how users, groups, applications and policies can be exported.
Treat these points as planning inputs for counsel, not as a compliance outcome. Certifications and attestations come from independent bodies, and the question of which obligations apply is a legal one. Ask counsel to confirm your NIS2 entity category, your CRA product classification and conformity route, the data processing terms in customer contracts, and whether your Data Act position covers identity services. Also confirm the licensing position: most authentik code is under the MIT license, while the authentik/enterprise/ directory is under a separate enterprise license. That split affects what you can embed, modify or distribute, and the Enterprise features you rely on should be checked against it before you commit them to a customer-facing product.
Where SaaS identity rollouts commonly go wrong
Most authentik rollouts for SaaS teams fail in predictable places: the platform's internals, the production database, the upgrade path, customer-facing configuration, licensing and audit evidence. Each card names the risk and the mitigation to plan for before go-live.
Carrying Redis assumptions forward
Teams that ran earlier authentik or other identity stacks with a Redis cache may still expect a Redis service in their design. The 2025.10 release moved caching, tasks, sessions and WebSocket functions to PostgreSQL and no longer uses Redis at all. Plan for the roughly 50% more PostgreSQL connections the release notes warn about, and check connection limits, pooling and monitoring before upgrading or sizing a new deployment.
Running the bundled chart database
The Kubernetes guide states that the PostgreSQL bundled with the Helm chart is for demonstration and test environments. Because authentik stores all configuration and data in PostgreSQL except uploaded files, a demo database in production puts sign-in, provisioning and audit history at risk. Plan a separately managed PostgreSQL with tested backups, high availability and restore procedures before go-live.
Skipping sequential upgrades
Upgrades are where SaaS teams lose the most time when they fall behind a supported line. The security policy lists the 2026.5.x and 2026.8.x lines as receiving security fixes, and the project announces security releases at least 24 hours ahead. Plan a staging environment that mirrors production, a dated upgrade calendar, a rollback path, and outpost version alignment so no tenant runs an unsupported build.
Leaving customer tenants without flows
A single default login flow works for internal staff but often fails customer organizations that need their own branding, invitation rules, password policies or recovery steps. Without per-domain flows and providers, one customer's configuration change can affect every other tenant. Plan a flow and policy model per customer domain, document who owns each one, and test sign-in for each tenant after changes.
Unclear Enterprise licensing
Most authentik code sits under the MIT license, but code in the enterprise directory follows a separate enterprise license. Google Workspace, Entra ID, mTLS, password history and enhanced audit logging are listed as Enterprise features. Before building custom directory connectors or copying modules, have legal confirm which code you ship, which license governs it, and whether your priced edition covers each feature you rely on.
Missing offboarding evidence
Access reviews and SOC 2 examinations ask for proof that departing staff and deprovisioned customer users lost access on time. Teams often revoke accounts in the directory but cannot show when the SaaS application, outpost or API token stopped working. Plan logging that captures deactivation and session events, a record of who approved each change, and a periodic check that the revocation reached every connected application.
How DeployOpen scopes and delivers authentik for SaaS teams
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For authentik, we agree the scope in writing before work starts, so the workforce, customer identity and access evidence work is defined before any configuration begins.
How we scope
- Inventory the SaaS and internal tools that need workforce SSO and which protocols each one supports
- Define the customer-facing login scope, including external user populations, brands and domains
- Agree in writing which Enterprise features are in scope and which are built or deferred
How we build
- Deploy authentik in your infrastructure with PostgreSQL, worker and server components sized to your plan
- Configure providers, applications, flows and policies for each SaaS and internal integration
- Test sign-in, MFA enrollment, group mapping and deprovisioning paths before any cutover
How we hand over
- Document the configuration, provider settings and access review steps your team will maintain
- Produce access evidence exports and runbooks that map to your SOC 2 control descriptions
- Train your platform and security staff on upgrades, release notes and rollback procedures
How we support
- Offer ongoing support, upgrades and testing as a retainer after handover
- Plan authentik version upgrades in sequence, checking release notes before each step
- Review access configuration changes with your team as your product and customer base grow
