A hundred terms behind Zero Trust, ZTNA, identity and the access controls that make them work. Each is defined in one plain paragraph, and each leads to the part of the platform where it turns up.
Proving who you are with one piece of evidence, almost always a password. One factor means one thing to steal, guess or phish, which is why every regulator that writes an access clause now asks for a second.
Multi-Factor Authentication →A login that needs two different kinds of evidence: something you know, such as a password, plus something you have, such as a phone or a hardware key. A stolen password on its own stops working.
Multi-Factor Authentication →Two-factor plus a third category, usually something you are: a fingerprint or a face. Used where the resource justifies the friction; most deployments get there through step-up rather than every time.
Multi-Factor Authentication →Multi-factor authentication delivered as a service rather than an appliance: the second factor is verified by a hosted platform that any application or gateway can call. Nothing to rack, and the same factor works for every app.
Multi-Factor Authentication →Putting a second factor in front of RDP so that a password alone cannot open a Windows session. Done properly it sits at the gateway, so the desktop itself never has to be reachable to be protected.
Multi-Factor Authentication →Verifying a person by a physical trait: fingerprint, face or iris. Strong because the factor cannot be forgotten or written down; it should still be one factor among several rather than the only one.
Multi-Factor Authentication →Matching a live biometric sample against a stored template to confirm a claimed identity. Distinct from identification, which asks who someone is; verification asks whether they are who they say.
Multi-Factor Authentication →Proving identity with a digital certificate issued to a person or a device. A device certificate is how an access platform knows the laptop is the laptop it approved, before any password is typed.
Device Binding →An open standard for phishing-resistant login using public-key cryptography: the private key never leaves the authenticator, so there is nothing a fake site can capture. Hardware keys and platform authenticators speak it.
Multi-Factor Authentication →The browser API through which websites use FIDO authenticators. It is what lets a login page ask for a fingerprint or a security key without any plugin, and what makes passkeys work.
Multi-Factor Authentication →A six-digit code generated from a shared secret and the current time, valid for about thirty seconds. Authenticator apps implement it; it works offline and does not depend on a phone network.
Multi-Factor Authentication →Verifying identity through things a person is supposed to know: security questions, a mother's maiden name. Its limitation is that the answers are guessable, searchable or already leaked, which is why it is no longer accepted as a factor on its own.
Multi-Factor Authentication →The umbrella term for token-based login built on OAuth 2.0 and OpenID Connect, with MFA and conditional access in the flow, replacing basic authentication where a password travels with every request.
Multi-Factor Authentication →One login that vouches for a person to many web applications, so they sign in once and each application trusts a signed assertion instead of asking for its own password.
Single Sign-On →An arrangement where one organisation's identity provider is trusted by another's applications. The user authenticates at home; the application receives a signed statement of who they are, via SAML or OpenID Connect.
Single Sign-On →Active Directory Federation Services: Microsoft's on-premise component that turns an Active Directory login into federated tokens applications can trust. Many estates keep it in place while a cloud identity layer sits in front.
Single Sign-On →The system that authenticates people and issues the assertions applications rely on. Every single sign-on flow has one; an access platform either is the IdP or takes its word for it.
Single Sign-On →The older category of products that put authentication and authorisation in front of web applications, usually through an agent or a reverse proxy. Its concern, who may reach which URL, lives inside Zero Trust application access today.
Single Sign-On →The authorisation framework that lets an application act on a person's behalf with a scoped token instead of their password. OpenID Connect adds the identity layer that makes it usable for login.
Single Sign-On →The discipline of knowing who someone is, what they may reach, and proving both on every request. Directories, authentication, authorisation and lifecycle in one place.
Identity & Access Management →Identity management for customers rather than employees: self-registration, consent, social login and scale, with the same authentication strength underneath.
Identity & Access Management →Identity and access management delivered from the cloud: directory, SSO, MFA and lifecycle as a subscription rather than servers you run.
Identity & Access Management →The database of people, groups and devices an organisation authenticates against. Active Directory and LDAP directories are the classic forms; a cloud directory plays the same role for SaaS.
Identity & Access Management →Microsoft's cloud directory and identity provider, now called Entra ID. Most estates sync it from on-premise Active Directory and let it issue the tokens SaaS applications trust.
Identity & Access Management →Logging in against an on-premise Active Directory domain, historically over Kerberos or NTLM. Remote machines that must still join the domain are exactly the case domain joining over Zero Trust exists for.
Identity & Access Management →Authenticating by binding to an LDAP directory with a username and password. Simple and everywhere; also the reason a second factor has to be added in front of it rather than inside it.
Identity & Access Management →A signed, self-contained token that carries claims about a user. Applications verify the signature instead of calling back to the issuer, which is what makes stateless API authentication possible.
Identity & Access Management →Proving who is calling an API and deciding what that caller may do: tokens, keys or certificates for the first, scopes and policy for the second. Machine identities need the same rigour as people.
Identity & Access Management →The three questions every access system answers: who are you, what may you do, and what did you do. RADIUS and TACACS+ are the protocols network equipment uses to ask them.
Identity & Access Management →A long secret string that identifies a calling application. Convenient and dangerous in equal measure: it is a password that never expires unless someone makes it, and it says nothing about the person behind the call.
Identity & Access Management →The set of DNS-published checks (SPF, DKIM and DMARC) that let a receiving mail server verify a message really came from the domain it claims. It protects the brand from impersonation, not the inbox from every threat.
Identity & Access Management →Publishing SPF, signing with DKIM, adding a DMARC policy, monitoring the reports, then moving the policy from monitor to reject. Five steps, each one a DNS record and a decision.
Identity & Access Management →Attacks that smuggle commands into API input: SQL, NoSQL, command or LDAP injection. The defence is validation and parameterisation at the API, and never trusting the caller more than the token proves.
Identity & Access Management →The most common categories of API vulnerability, ranked. Broken object- and function-level authorisation lead the list, which is why authorisation, not just authentication, decides whether an API is safe.
Identity & Access Management →Creating the accounts and entitlements a person needs when they join or change role. Done by hand it lags; done from the directory it happens the day HR says so.
Identity & Access Management →Creating and updating accounts across applications from one source of truth, without tickets. SCIM is the usual protocol; the directory is the usual source.
Identity & Access Management →Removing access when a person leaves or a role ends. The half of lifecycle that matters most to an auditor, because an account that outlives its owner is a credential nobody is watching.
Identity & Access Management →The full cycle: grant on join, adjust on move, revoke on leave. One directory group driving every application is what turns offboarding into a single action.
Identity & Access Management →Creating an account in an application the first time a person signs in through single sign-on, from the attributes in the assertion. No pre-creation, no orphaned accounts for people who never showed up.
Identity & Access Management →Managing identity from onboarding through every role change to offboarding, with entitlements following the person's status in the directory rather than in someone's memory.
Identity & Access Management →The everyday administration of accounts, groups and attributes. Consolidated in one console it is a task; spread across fifteen applications it is a headcount.
Identity & Access Management →Letting people reset their own password after proving identity another way, usually a second factor. Removes the commonest helpdesk ticket and a favourite social-engineering route in one move.
Identity & Access Management →The formal ways of deciding who may do what: discretionary, mandatory, role-based and attribute-based. Modern access policy mixes role with attributes such as device posture, location and time.
Contextual Access →Granting permissions to roles and assigning people to roles, so access follows the job rather than the individual. Simple to audit; it needs attributes alongside it to say when and from where.
Contextual Access →Access decided by conditions evaluated at the moment of the request: device state, location, network, time and risk, alongside who is asking. A policy engine is what evaluates them.
Contextual Access →Allowing or refusing access according to where the request comes from, by IP or device location. Useful as one signal; never as the only one, because location is easy to spoof and easy to be legitimately wrong about.
Contextual Access →The class of flaw where an application fails to enforce what a user may do, so changing an ID in a URL or calling an admin endpoint works. Prevented by deny-by-default authorisation checked on the server for every request.
Contextual Access →Authentication proves who you are; authorisation decides what you may do. Confusing the two is how a valid login ends up with far more reach than it should.
Contextual Access →An API flaw where a regular user can call functions meant for another role, usually an administrative one, because the check exists in the interface and not in the API.
Contextual Access →An API flaw where a user can read or change objects that belong to someone else by changing an identifier. Fixed by checking ownership on every object access, server-side, without exception.
Contextual Access →Accounts that can change systems rather than just use them: administrators, root, service accounts, database owners. The accounts an attacker wants most and an auditor asks about first.
Privileged Access →Controlling, recording and reviewing what privileged accounts do: vaulting credentials, brokering sessions, recording them and expiring the grant. The session, not the password, becomes the unit of control.
Privileged Access →Granting elevated rights for a window of time on request, with approval and a record, instead of leaving them permanently attached to an account.
Privileged Access →Letting a standard user run a specific privileged action, or delegating a slice of an administrator's rights, without handing over the whole account.
Privileged Access →Every person, device and process gets the minimum access the task needs, for the time it needs it. The principle underneath Zero Trust; a per-application session is what it looks like in practice.
Privileged Access →Administrators and vendors reaching servers, databases and consoles from outside, under harder gates and with the session recorded. The case where a network-level VPN is most dangerous and a brokered session most useful.
Privileged Access →Brokering, monitoring and recording sessions on sensitive systems so that what an administrator did is a replayable record rather than a reconstruction.
Privileged Access →An encrypted tunnel that puts a remote device on a private network as if it were plugged in. It protects the traffic in transit and, as a side effect, hands the device the whole network. That second part is the problem Zero Trust exists to remove.
VPN Alternative →A VPN run by an organisation for its people rather than a consumer privacy product. Same tunnel, same network-level grant, plus a concentrator that must listen on the public internet.
VPN Alternative →Business VPN at scale: hardware sized for peaks, refreshed on cycles, and a route onto the network for every connected device. The category being replaced by per-application access.
VPN Alternative →A permanent tunnel joining two networks, typically two offices or an office and a cloud. Reasonable between infrastructure; the wrong tool for people, who need an application, not a network.
VPN Alternative →A router feature that lets VPN protocols traverse network address translation. A reminder that the traditional tunnel was designed around network plumbing, not identity.
VPN Alternative →The VPN a remote worker dials into to reach the office network. The file share, the internal app, the RDP host: Zero Trust access serves all of them without the network membership.
VPN Alternative →A tunnel that comes up when the device boots, before anyone logs in, so managed machines are always reachable by IT. The Zero Trust version does the same off a device certificate, with no network exposed.
Always-On Connectivity →A VPN grants a network; ZTNA grants an application. That one difference decides lateral movement, internet exposure, latency and how hardware is bought. The comparison is architectural, not a feature list.
VPN Alternative →A security model that assigns no implicit trust to any user or device, verifies every request continuously, and grants the least access the task needs. Not a product: a set of principles a platform enforces.
What is Zero Trust? →The access technology that implements Zero Trust for private applications: verify the person and the device, then connect them to the one application requested through a tunnel scoped to it. The network stays invisible.
Zero Trust Network Access →Protecting the integrity and reachability of a network and what runs on it. Its perimeter version assumed inside meant safe; its Zero Trust version assumes nothing and verifies each request.
Zero Trust Network Access →Dividing a network into zones so that a breach in one cannot reach the others. Micro-segmentation takes it to the application, and per-application access takes it to the session.
Zero Trust Network Access →Securing the servers, networks, endpoints and cloud resources an organisation runs on. In a Zero Trust design the first control is that none of it is reachable until a request has been verified.
Zero Trust Network Access →A control point between users and SaaS that discovers, monitors and governs cloud application use, shadow IT included. It answers what people do inside SaaS; access control answers whether they get there.
Secure Cloud Access →A hosted intermediary that traffic passes through for inspection or policy. Useful for web filtering; it also means a vendor sees the traffic, which is what a split-plane design avoids.
Secure Cloud Access →One platform serving many customers on shared infrastructure, with isolation enforced in software. Standard for SaaS; the questions to ask are how tenants are separated and whose data transits what.
Secure Cloud Access →Protecting the virtual networks, gateways and connections inside a cloud estate. Security groups and private endpoints on one side; identity-based access to the workloads on the other.
Secure Cloud Access →Securing the running things (VMs, containers, functions) rather than the network around them. Access to the workload's management plane is where identity-based control matters most.
Secure Cloud Access →One security model across on-premise and cloud so that policy, identity and logging do not fork when a workload moves. An access layer above the hosting decision is how the model stays single.
Secure Cloud Access →The split between what a cloud provider secures and what the customer must: the provider runs the infrastructure, the customer decides who may reach what runs on it. Access control is always on the customer's side of the line.
Secure Cloud Access →Protecting laptops, phones and servers from compromise, and knowing their state. In an access decision the endpoint's posture is evidence, not an afterthought: disk encryption, patch level, running protection.
Device Posture Check →Endpoint defence that goes beyond signature antivirus: behavioural detection, exploit prevention, response. Its status is one of the checks an access platform can read before granting a session.
Device Posture Check →The marketing name for the same shift, from known-bad signatures to behaviour and response. Whatever it is called, whether it is running and current is a posture check.
Device Posture Check →Configuring, patching and inventorying devices at scale, typically through MDM or a management agent. Access control complements it by reading the result: a device that fails policy reaches less.
Device Posture Check →Reducing what a device exposes: disabling what is not needed, enforcing encryption, keeping it patched. Hardening lowers the chance of compromise; posture checks make the hardening a condition of access.
Device Posture Check →Defences aimed at targeted, evasive attacks rather than commodity malware. Zero Trust reduces what such an attack can reach once it lands, which is the part detection cannot promise.
Endpoint Controls →Software written to harm: viruses, worms, trojans, spyware, ransomware. The access-control answer is containment: an infected device reaches one application, not a network.
Endpoint Controls →Malware that encrypts data and demands payment for the key, usually spreading laterally first. Removing the lateral path is what limits a single infection to a single machine: no network membership, and one session per application.
Endpoint Controls →Controls that stop sensitive data leaving where it belongs: blocked copy, download and upload, and watermarked screens. They work best at the point of use, which is the session and the tab.
Endpoint Controls →Classify what matters, decide where it may go, enforce at the points where it could leave, and log what was refused. The enforcement points that work on unmanaged devices are the session and the browser.
Endpoint Controls →A DLP technique that fingerprints specific records, a customer table or an account list, so only those exact values trigger a rule rather than anything that looks like a number.
Endpoint Controls →Unauthorised access to or disclosure of protected data. Most breaches are a credential plus a reachable path; Zero Trust attacks the path, and the log is what tells you the scope afterwards.
Compliance & Regulatory →Allowing or refusing web destinations by address or category. Enforced in the browser it applies before a request leaves the device, on any network, including the one at home.
Secure Enterprise Browser →Blocking web content by category or type rather than by address alone. A governed browser applies it per user and per policy, without routing the traffic through a proxy first.
Secure Enterprise Browser →The general term for controlling which web resources can be reached. Historically a network appliance; increasingly a property of the browser, where the policy travels with the person.
Secure Enterprise Browser →Temporarily deferring an unknown sender or destination and allowing it only if it retries or is later classified. In web filtering it is the middle state between allow-list and block-list.
Secure Enterprise Browser →Hosting whole desktops on servers and streaming them to users. Bought for control, paid for in farms and latency; when the goal is a governed application rather than a whole desktop, publishing the application is the lighter answer.
VDI Alternative →Building security into the development pipeline rather than checking for it at the end. Access to the toolchain (repositories, CI, staging, production) is the part an access platform governs.
DevOps Security →Making security a property of the architecture so that compliance follows from how the system works rather than from controls bolted on later. A split plane, a drop-all gateway and a session log are secure-by-design decisions that also answer audit clauses.
Compliance & Regulatory →//Ready when you are//
A 30-minute walkthrough turns the definitions into the platform running against your own applications.
Regulated, air-gapped, or on-premise? See deployment options