Identity & SSO
Give employees and customers secure access to every app with one account
Your Active Directory stays where it is, while single sign-on, multi-factor authentication and access control run on Nesnet's own NIM platform, at an address like login.yourcompany.com.
Why now
- Every employee juggles fifteen apps and fifteen passwords. Someone left accounting, their AD account was disabled, but their cloud app account stayed open for three months until an auditor spotted it.
- A marketing manager's password was stolen through a phishing email, and the account was used from abroad at midnight. With a second factor, the password alone would have been useless.
- A major customer's contract requires you to review who has access to what every quarter and to document separation of duties. A spreadsheet review is slow and proves nothing.
- You need customer sign-in in your software. Building sign-up, email verification and password reset screens from scratch is a separate project whose maintenance never ends.
- Opening Active Directory to cloud apps would mean an inbound firewall rule, and your security team won't accept the risk.
What changes
| Today | With Nesnet |
|---|---|
| Every app has its own password, and people reuse the same one everywhere. | People sign in once, on a page at your own domain, and reach every app. |
| A leaver's accounts are closed app by app, and one always gets missed. | An account disabled in AD can't sign in to NIM, so it can't reach any app behind NIM either. |
| One stolen password opens every door. | Sign-in asks for a push approval or code on the phone, with extra checks for risky sign-ins. |
| Access reviews run on spreadsheets and email, with scattered evidence. | Requests, approvals and periodic reviews happen in the console, and every decision is recorded. |
| Bringing AD to the cloud means an inbound hole in the firewall. | The connector on your network only dials out; not a single inbound port is opened. |
From today to live: how it works
- 1
Discovery call
You and the Nesnet team agree how many users you have, which apps need connecting and where your directory lives. By the end of the call you have a rollout order and the items that set the price.
- 2
Your tenant opens
Nesnet creates your tenant, and you sign in to the admin console at your organization's own address. A setup checklist on the first screen asks you to turn on MFA, connect your first app and set your branding.
- 3
Your directory connects
The Windows directory connector installs from an MSI on a server in your network; the wizard finds your AD domain itself and only asks for a service account. Users without AD are imported from CSV and invited in bulk.
- 4
First apps and a pilot group
You connect your first few apps with the app wizard and try single sign-on and the second factor with a small pilot group. Once it runs smoothly, the remaining groups follow one by one.
- 5
Company-wide rollout
The remaining apps are connected, the second factor becomes mandatory for everyone and old passwords are retired. The audit trail and security score show your progress from day one.
What you get
Single sign-on to every app
People sign in once and move into every app they're allowed to use without typing a password again. Apps connect over OpenID Connect / OAuth 2.0 or SAML 2.0, and SAML sign-in works whether it starts at the app or at the identity provider.
Connect Active Directory without moving it
Directory users are checked live against their AD password at sign-in, and their profile fields belong to the directory, read-only in NIM. There's no user migration, no password reset campaign and no new account to hand out.
No inbound holes in your firewall
The directory connector installs on a Windows server in your network and connects to NIM outbound only, over an encrypted connection on port 443. No inbound rule is added to your firewall, and your AD never faces the internet.
Password changes write back to AD
When a user changes their password in NIM's portal, the new password is written back to Active Directory. Employees remember one password, and the help desk doesn't reset two systems separately.
A second factor approved on the phone
With multi-factor authentication, users approve a sign-in by tapping a notification in the NIM Authenticator app or enter its one-time code. A stolen password alone is no longer enough, and recovery codes keep the door open if the phone is lost.
Access decided by context
Sign-ins from a new network, a new country or at impossible travel speed are asked for an extra check. Conditional access rules allow, step up or block a sign-in based on user, group, app, country and device context.
Sign in with external accounts
Google, Microsoft Entra, GitHub, Facebook and LinkedIn sign-in come ready, and any other OpenID Connect or SAML provider can be added. Local users, AD users and external-account users are managed side by side in one console.
Your own domain, your own look
Point the sign-in address to your own domain, such as login.yourcompany.com, and the encryption certificate is issued and renewed automatically. Set your own font, background and colors with a live preview, and invitation and password-reset emails go out with your branding.
Group-based access with an app gate
Everyone in a group inherits the roles assigned to it; the role is written into the token sent to the app and becomes a permission there. A user without a role for an app gets no token, and the sign-in is refused in NIM before it ever reaches the app.
Leavers lose access in one step
When an account is disabled in AD, its sign-in stops at once and open sessions are closed in the next periodic sweep. Admins can end all of a user's sessions with a single action, so no forgotten app is left on the offboarding list.
Provision users automatically
With SCIM 2.0, users and groups flow from another identity provider into NIM, and from NIM into apps that speak SCIM. A new starter's accounts are ready on day one, and a leaver's accounts are cleaned up by periodic reconciliation.
Access requests and approvals
Employees request the access they need in the portal, and approvers record their decisions there. Permissions that usually go together are bundled into access packages, so a new sales rep's six apps open with one request.
Periodic reviews and separation of duties
Periodic reviews ask the owner of each access whether it is still needed, and the answer is recorded. Separation-of-duties rules stop two conflicting permissions, such as approving payments and adding suppliers, from landing on the same person.
A password vault for legacy apps
For older apps that don't support single sign-on, passwords are stored encrypted and the sign-in form is filled in on the user's behalf. Admins can't read anyone else's password, and a leaver's vault access closes along with everything else.
Audit trail and SIEM export
Sign-ins, password changes, MFA events, lockouts and admin actions are recorded with who, when, from which IP, to which app and with what result. Records are kept for a year by default and stream to your own SIEM over syslog or webhook.
Ready-made reports and a security score
The security score on the tenant console's home screen lists what is pulling it down in order of importance and links each item to the screen that fixes it. Reports are generated on the server, downloaded as PDF or CSV and scheduled for the date your auditor needs.
KVKK processes built in
Privacy notices are accepted at sign-in, and the system records who accepted which version and when. Consent purposes are managed one by one, users can download a full copy of their own data, and an admin delete reaches every connected store.
A self-service portal for employees
Employees land on a page where every app they're allowed to use opens in one click; they change their password, see and close their sessions and download their own activity history. A user who forgets their password resets it without calling the help desk.
Passwordless cluster access for developers
When a Kubernetes cluster is connected to NIM, full, edit and read roles are created, and users download a kubeconfig with no password inside or open an in-browser terminal. The image registry gets a one-time CLI secret, and the VPN gets a personal profile.
Sign-in for your own product's customers
Sign-up, email verification, your own domain and branded sign-in are ready for your product's customers. Each project is an isolated space with its own user pool, domain and branding, and solution partners can open separate projects for their own customers.
Why Nesnet
Nesnet's software, an open-source engine
NIM's identity engine is open source, and we say so plainly. The multi-tenant control plane, the three portals, the Active Directory connector and the NIM Authenticator app on top of it are code written by Nesnet's team, not someone else's identity service resold under a new label.
Nesnet signs in to its own systems with NIM
Nesnet's cloud portal, image registry, Kubernetes, SD-WAN console and VPN sign-ins all go through NIM. The identity platform you get is the same one Nesnet's administrators use every day to sign in to their own platforms.
Your data stays in Türkiye
User, session and audit data stay in Türkiye, on Nesnet's infrastructure in the Equinix Istanbul (Dudullu) and Türk Telekom Ankara facilities. Bot protection on the sign-in page runs on Nesnet's own servers, so visitor data never goes to a third-party service.
Built in Turkish, documented in Turkish
The admin console and the employee portal work in Turkish and English, and the product guides are written in Turkish. KVKK privacy notices and consent receipts come built into the product, with no extra tool needed.
Governance without an add-on
Access requests and approvals, periodic reviews, separation of duties and a password vault for legacy apps are all in the same console. The pieces other providers sell as extra packages don't need a second contract.
Nesnet’s own product, supported locally
Nesnet develops and runs NIM. For an integration question or an incident, Nesnet’s support team helps you in Turkish or English.
Example scenarios
A leaver's accounts
Situation
At a distribution company on Active Directory, people sign in separately to around fifteen apps. When someone leaves, their AD account is disabled but their cloud app accounts are forgotten.
Outcome
Once the apps are connected to NIM, an account disabled in AD can't sign in to NIM, so it can't reach any app behind it, and open sessions close in the sweep. The audit trail shows when each app was last used.
A stolen password, a blocked sign-in
Situation
At an insurance agency, an employee typed their password into a phishing page. That same night, the attacker tried to sign in from another country.
Outcome
Because the sign-in came from a new country, an extra check was required; the push on the phone was rejected and the attempt landed in the audit trail. In the morning the admin reset the password and closed all sessions in one action.
A quarterly access review
Situation
A payments company has to review who can reach which system every quarter and prove separation of duties. The review used to drag on for weeks over email.
Outcome
The review campaign was launched from the console, each access owner decided in the portal, and the result went to the auditor as a PDF report. Separation-of-duties rules now stop conflicting permissions from being granted in the first place.
Customer sign-in for a software product
Situation
A software house wants customer sign-up and sign-in in the app it sells. It doesn't want to build and maintain sign-up, email verification and password reset screens itself.
Outcome
A separate project was created in NIM for the app, and customers sign up and verify their email on a branded sign-in page. The team only had to connect the app over OpenID Connect.
One identity for a developer team
Situation
A developer team reached its Kubernetes clusters with shared kubeconfig files and the image registry with a common password. When a developer left, nobody was sure what they could still reach.
Outcome
The clusters and the registry were connected to NIM, and every developer now downloads a passwordless kubeconfig under their own identity. A leaver's access closes together with their AD account.
Who does what
| Nesnet | You |
|---|---|
| Develops, runs and updates NIM, keeping it redundant in production. | Install the directory connector on a server in your network and keep it running. |
| Opens your tenant and sets a minimum security baseline for every tenant. | Decide which groups reach which apps and what the roles are. |
| Issues and renews the encryption certificate for your custom domain. | Connect your apps to NIM over OIDC or SAML. |
| Runs bot protection and breached-password checks on its own infrastructure. | Start periodic access reviews and follow up on their results. |
| Develops the NIM Authenticator mobile app and keeps it current. | Present privacy notices and consent purposes to your people with content you prepare. |
Who it is for
Organizations on Active Directory
Companies that have run Active Directory for years and want single sign-on, a second factor and an audit trail without moving users anywhere. People keep signing in with their AD password; what changes is that every app opens through the same door.
Audited and regulated organizations
Finance, healthcare and public-sector suppliers that must regularly document who reached which system and who approved it. Access requests, approvals, reviews and separation of duties are all recorded in one console.
Software teams that need customer sign-in
Software houses that want sign-up, email verification and branded sign-in in their own product. Each product lives in its own project with its own user pool, domain and branding, so you never build login screens from scratch.
Developer teams on clusters and VPN
Teams working with Kubernetes, an image registry and a VPN. They reach the cluster, the registry and the VPN with the same identity, and no kubeconfig file or shared password gets passed around.
Remote and multi-site workforces
Organizations whose people reach cloud apps from home, the field and branch offices. Sign-ins from a new country or an unusual network trigger an extra check, and access can be limited to specific countries.
May not be the right fit
Teams looking for a directory server their applications can query over LDAP. NIM connects to your directory but does not act as an LDAP server for applications; those apps stay connected to Active Directory, while web and mobile apps connect to NIM over OIDC or SAML.
Small teams with a single application that are happy with that application's own user management. Using the app's own sign-in and second factor is less work in that case.
Under the hood
NIM is an open-source identity engine with a Nesnet-built control plane, portals and engine extensions on top. User, session and configuration data sit in a relational database that Nesnet operates. The control plane manages tenants, branding, custom domains and security policy, and extensions add Nesnet-specific sign-in steps to the engine. There are three separate surfaces: the provider console Nesnet uses, the tenant console your administrators use, and the self-service portal your people sign in to. All three run in Turkish and English and offer light and dark themes. Your tenant console opens at yourcompany-admin.id.nesnet.com and the portal at yourcompany.id.nesnet.com; sign-in can move to your own domain, such as login.yourcompany.com, with the TLS certificate issued automatically.
Building blocks
- Identity engine and Nesnet control plane
- OpenID Connect, SAML 2.0 and sessions; tenants, branding, domains and policy are Nesnet's code
- Nesnet engine extensions
- Nesnet-specific sign-in steps and behaviour inside the engine
- Automatic certificate management
- issues and renews the TLS certificate for the custom domain
- Three portals
- provider console, tenant admin console, end-user self-service portal
- Directory connector (Windows, MSI)
- runs in your network, connects out to NIM over TLS/443 only
- Identity database
- user, session and configuration data; operated by Nesnet
- NIM Authenticator (iOS and Android)
- push approvals and one-time codes
How it compares
| Option | When it is the right choice |
|---|---|
| Run an open-source identity server yourself | The right choice if you want the identity engine on your own infrastructure and have a team to handle upgrades and the database; NIM's engine is open source as well. You would then build or assemble the multi-tenant console, the AD connector, branding, access reviews and a mobile authenticator yourself. |
| Stay on Active Directory alone | If every application runs inside the corporate network and nothing is published to the web, AD may be all you need. Once cloud apps, remote staff or customer sign-in arrive, AD needs an identity provider (IdP) beside it, and NIM adds that layer without moving AD. |
| Let each application manage its own users | With one or two applications and a handful of people, separate accounts per app are manageable. As the app count grows, closing a leaver's accounts one by one and knowing who can reach what gets hard, and that is where a single identity pays off. |
Technical specifications
| OpenID Connect / OAuth 2.0 | Authorisation code with PKCE |
|---|---|
| PKCE and redirects | S256 mandatory for browser and mobile clients; exact redirect URI match |
| SAML 2.0 | SP- and IdP-initiated flows |
| Advanced OAuth flows | Token exchange (RFC 8693), DPoP, PAR, Device Authorization Grant (RFC 8628); per application |
| Sign-out | RP-initiated logout, per-app back-channel logout, end all of a user's sessions in one action |
| Token contents | sub, email, groups, app-specific roles · JWKS-verifiable signature |
| Directory | Active Directory / LDAP binding (directory side only; NIM is not an LDAP server for apps) |
|---|---|
| Connector direction | Outbound TLS/443 (WebSocket) only; no inbound ports |
| Connector install | Windows MSI; wizard discovers the AD domain and domain controller |
| Disabled AD account | Sign-in stops at once; open session closed by sweep, 15 minutes by default |
| Password writeback | Passwords changed in NIM are written to AD |
| External identity providers | Google, Microsoft Entra, GitHub, Facebook, LinkedIn; any custom OIDC / SAML provider |
| Custom domain | login.yourcompany.com (CNAME); automatic TLS certificate; removable provider credit |
|---|---|
| Branding | Own web font, background, custom CSS, live preview |
| System emails | Branded templates; your SMTP server or the platform's |
| Interface language | Turkish and English; light and dark themes |
| Audit trail | Who, when, IP, application, result |
|---|---|
| SIEM export | RFC 5424 syslog (UDP/TCP), CEF or JSON; webhook |
| Log retention | 365 days by default |
| Reports | Server-side; PDF / CSV; schedulable |
| Breached-password check | k-anonymity (first 5 characters of the SHA-1 hash) |
| Bot protection | Proof of work on Nesnet's server; no picture puzzles |
| Risk signals | New network, new country, impossible travel (IP geolocation data) |
| Session limits | Concurrent session cap (off by default), sign out everywhere |
| Engine and layers | Open-source engine + Nesnet-written control plane, portals and engine extensions |
|---|---|
| Billing unit | Per user |
If something breaks
An employee's AD account is disabled
Their NIM sign-in stops immediately, because the password is checked against AD on every sign-in. A browser session left open is closed by the periodic sweep, within 15 minutes by default.
A user loses their phone or second factor
The user signs in with one of the recovery codes shown to them once at enrolment. If those are gone too, an administrator resets the registered method from the user's detail page and the user enrols a new one.
You suspect an account is compromised
An administrator ends all of that user's sessions in one action. The audit trail shows which IPs and applications the account used and when, and the same records have already reached your SIEM.
Frequently asked questions
Pricing and first steps
Pricing
Identity and SSO is priced per user and billed monthly. Multi-factor authentication is a separate per-user line, and the NIM Authenticator mobile app costs nothing extra.
What the price depends on
- The number of users with an account in NIM
- Whether multi-factor authentication is added as its separate per-user line
- No extra charge for the NIM Authenticator mobile app your users install
How to get started
- 1.Fill in the form or call 0800 606 1071.
- 2.We agree on user count and the apps to connect in one call and prepare a price.
- 3.The tenant is created; you connect your directory and add your first app.
Start your move to one identity with a single call
Tell the Nesnet team how many users and which apps you have, and you'll hear back within the same business day. Your Active Directory stays put, no inbound port is opened, and the sign-in page opens at your own address.