How to implement a Zero Trust architecture with least-privilege access, starting from identity management

A Zero Trust architecture with least-privilege access is implemented from identity in three moves: bring every login onto a single decision point (an IAM platform integrated via SDK or REST API, with SSO and MFA), reduce every identity — human and non-human — to the permissions it needs per tenant and project, and make revocation immediate and measurable. With LoginMaster, segmentation already happens at the identity layer: every tenant and project has its own cryptographic keys, every token carries a double signature (Tenant and Cloud), and not even the vendor is a trusted party, because personal data stays on the customer's tenant.

This is the hands-on guide. For the definition of the model and its principles start from what is Zero Trust; for the product controls see Zero Trust with LoginMaster.

Why start from identity rather than the network

Zero Trust initiatives that start from the network (microsegmentation, ZTNA, VPN replacement) often stall on the same question: "who, exactly, is the entity requesting access, and what should it be allowed to do?". If the answer lives in ten applications with ten different user bases, no network component can make a correct decision. The practical starting point is therefore the identity control plane: one place where identity is verified, context is known and policy is declared.

• Compromised credentials remain one of the most frequent initial access vectors: an identity control neutralises them regardless of the network they come from.
• Remote work, SaaS and external partners have already moved requests outside the perimeter: identity is the only attribute that travels with every request.
• Least privilege is by definition a property of identities and roles, not of IP addresses.
• NIS2 (Art. 21) and ISO/IEC 27001:2022 (controls 5.15-5.18 and 8.5) require evidence on access control, identity management and secure authentication: starting from identity also produces the audit evidence.

The references: NIST SP 800-207 and CISA ZTMM 2.0

NIST SP 800-207: the seven tenets as identity requirements

NIST Special Publication 800-207 (August 2020) defines the reference architecture: a Policy Decision Point (Policy Engine + Policy Administrator) that decides, and a Policy Enforcement Point that enforces the decision in front of the resource. In the "identity-driven" approach the document describes, the PDP is largely the IAM platform. The seven tenets, read from the identity angle:

CISA Zero Trust Maturity Model 2.0: where you are on the Identity pillar

The CISA maturity model (version 2.0, April 2023) organises Zero Trust into five pillars — Identity, Devices, Networks, Applications and Workloads, Data — with three cross-cutting capabilities (Visibility and Analytics, Automation and Orchestration, Governance) and four stages: Traditional, Initial, Advanced, Optimal. Use it as a self-assessment before planning, not as a compliance checklist.

Phase 1 (days 0-30) — Visibility and a single decision point

Inventory: the identities nobody has counted

The inventory is not a spreadsheet of employee names. For each application you need four facts: who accesses it, with which type of credential, with which effective privileges, and which owner can say whether those privileges are still justified.

Centralised login via SDK and REST API

The first concrete result is that no application verifies a password on its own any more: authentication, second factor and policy are delegated to the IAM platform, which returns a signed token to the application. In LoginMaster every application is a project with independent security configuration on the tenant's shared user base, integrated with the official TypeScript and .NET SDKs or via REST API. For employees, SSO with Microsoft Entra ID or Google Workspace over OAuth 2.0 / OpenID Connect keeps the corporate directory as the source of truth: the procedure is in the guide to SSO with Entra ID and Google Workspace.

Mandatory MFA for administrators from day one

You do not need to wait for the role model to protect the highest-impact accounts. Make TOTP 2FA mandatory on administration projects and privileged roles, with an enrolment grace period: those who are not compliant by the deadline can be deactivated. In LoginMaster, once a user has enabled the second factor, no administrator can turn it off: this is the control that shuts down social engineering against the helpdesk. The operational detail is in the guide to TOTP and conditional access on internal apps.

Phase 2 (days 30-90) — Least privilege and identity segmentation

The role model: deny by default, per tenant and per project

Least privilege almost always fails for the same reason: you start from the permissions people have today and try to remove some. The method that holds is the opposite: every role starts with zero permissions and receives only those justified by a documented activity. Three design rules:

1. 1Roles bound to the project, not global: 'operator' on the billing project is not 'operator' on the production project. In LoginMaster roles live in the tenant and project context, and a user linked to one project does not see the others.
2. 2Explicit separation of duties: whoever approves a payment does not execute it, whoever manages users does not administer keys. List incompatible role pairs and check them at every assignment.
3. 3Few, well-named roles: a model with more roles than people is a model nobody will ever recertify.

A detail that matters in audits: in LoginMaster the administrator is not all-powerful. No administrator can read or set a user's password, email or second factor, and access recovery goes through a recovery code held by the user plus an approved request. That is least privilege applied to the people who run the platform too. The stated trade-off: without administrative reset, account recovery is slower. Details on access governance.

Conditional access: the signal → decision table

Zero Trust requires every access to be decided by policy. The practical question is which conditions the policy uses. In LoginMaster risk is expressed through static, declared policies on tenant, project and role — TOTP 2FA disabled, optional or mandatory, plus session and lockout parameters — not through a risk score computed in real time: every decision is explainable and auditable. This is what you configure today:

To keep policies reviewable, write them as a matrix before configuring them. The following example is illustrative pseudocode, not the product's configuration format:

tenant: acme
projects:
  deploy-console:   { criticality: high, session: 15m, max_attempts: 5 }
  billing:          { criticality: high, session: 1h,  max_attempts: 5 }
  internal-wiki:    { criticality: low,  session: 8h,  max_attempts: 10 }
2fa_rules:
  - if: criticality == high          then: mandatory
  - if: role in [admin, approver]    then: mandatory
  - else:                            optional
sign_up:
  authorised_domains: [acme.com]
sso_enabled: [entra-id]
enrolment_grace_period: 14d

Segmentation at the identity layer: keys per tenant and per project

Network microsegmentation separates flows; cryptographic identity segmentation separates trust. In LoginMaster every tenant and every project has its own keys and every token is signed twice (RS256), by Tenant and Cloud: a token issued for project A fails validation in project B, and not because of an application check someone might forget. That is "assume breach" applied to identity: the compromise of one context does not spread to the others.

There is a second, often overlooked level: the IAM vendor. In many platforms the vendor is implicitly a trusted party, because it holds credential hashes and personal data. In LoginMaster's Tenant-Cloud architecture personal data stays on the customer's tenant and the Cloud only works on encrypted, pseudonymised data; passwords are protected with Argon2 and split-salt between Tenant and Cloud. The vendor therefore cannot access the identities it manages: "never trust" extended to the supply chain. The mechanism is explained in how an IAM where the vendor cannot read passwords works.

Non-human identities: services, devices, AI agents

A Zero Trust programme that covers only people leaves the largest share of identities open. The rules are the same, with different credentials:

• One identity per service, device or agent, never shared: in LoginMaster a device is a subject type distinct from a user, with its own credentials.
• API keys for server-to-server traffic, individually revocable without affecting other identities.
• Native AWS IoT support over MQTT for devices, managed from the same console as users and applications.
• AI agents with their own identity and permissions, never with a developer's personal token: the agent should be able to do less than the person it acts for, not more.
• Credentials protected with Argon2id and split-salt and validated by double-signed tokens, isolated per tenant.

Further reading: AI agent identities, IoT device identities and the guide non-human identities: IoT, API keys and AI agents.

Phase 3 (days 90-180) — Lifecycle, revocation and measurement

Joiner-mover-leaver as API operations

Least privilege decays over time: people change role and accumulate permissions ("privilege creep"). The only remedy that scales is to tie the lifecycle to automatic events.

In LoginMaster provisioning and revocation are automated today via REST API and the TypeScript and .NET SDKs. At offboarding, deleting the subject is not enough: the procedure must revoke project access, API keys and active sessions as distinct steps, and verify each one. Session revocation is enforced server-side through token blacklisting, so a revoked session truly stops being valid. With Entra ID / Google Workspace federation, a user disabled in the directory can no longer authenticate. SCIM 2.0 provisioning and lifecycle webhooks are on the roadmap: the HR integration pattern is in the guide provisioning and lifecycle via REST API and SDK and on user provisioning.

Periodic access recertification

Quarterly for privileged roles, yearly for the rest, the owner of each application confirms or revokes the privileges of the people and non-human identities on their project. Recertification only works if the role model is small and the owner sees the right data: who holds the role, since when, last access. It is the evidence ISO/IEC 27001 (control 5.18) and NIS2 expect to find.

Visibility: identity events and SIEM

The seventh NIST tenet asks you to collect information to improve posture. LoginMaster's native SIEM connector (Syslog CEF over TLS, towards Splunk, QRadar, Sentinel or Elastic) is on the roadmap: until it ships, forwarding identity events to the SIEM has to be planned as a dedicated integration task, best agreed with the vendor before committing to an audit date. Which events you need and how to map them to controls is in the guide access logs for ISO 27001 and SIEM; the current status of each feature is on about us.

The KPIs to measure (before, during and after)

Without measurement, Zero Trust stays a statement of intent. Measure these indicators at the end of phase 1 as a baseline and then monthly; the directions below are guidance to tune to your organisation, not guaranteed results.

The mistakes that sink the project

• Starting by buying a network product before knowing who accesses what.
• Applying MFA to everyone with the same intensity: friction pushes people towards shortcuts. Policy-based MFA puts the cost where the risk is.
• Leaving SaaS and IAM vendors implicit access to data: a vendor that can read credentials is an undeclared trusted party.
• Forgetting non-human identities, which often outnumber human ones and never log out.
• Treating the project as finished: without recertification and KPIs, least privilege drifts back to most privilege within a year.
• Accepting features declared as supported when they are not: in vendor selection always ask what ships today and what is on the roadmap.

Where LoginMaster fits in the architecture

LoginMaster is a European IAM and CIAM platform, designed and built in Italy, with flat pricing per tenant and project and unlimited users: extending Zero Trust to customers, partners and non-human identities does not grow a per-user bill. For the related regulatory obligations see GDPR and NIS2 compliance, ISO 27001 alignment and the guide NIS2 and access management; if you manage both employees and end customers, the distinction is in IAM vs CIAM.