Identity says who is asking. Context says whether this request — now, from here, on this device — makes sense. Both are checked on every request, and re-checked while the session is still open.
sophia.s@veno.co.in
RequestingFinance Portal
Access allowedSession started
Step-up requiredOne more factor
Authentication proves who. Context decides whether.
Contextual access control evaluates the circumstances of a request — where it came from, when it arrived, what device it runs on, which role is asking — alongside the identity making it, and decides what to do about the combination.
Every one of these authenticates correctly. In every one, access should not be granted on the same terms — which is the entire job of contextual access.
An offboarded contractor's account was disabled in the directory on Friday. The service account they were also using was not. Every credential presented on Monday is valid — only an access window that ended with the engagement catches it.
svc_reporting_extContractor · offboarded Fri
Directory accountDisabled
Service accountStill live
A user authenticates from Pune at 09:14 and again from another continent at 09:41. Both logins are legitimate on their own. The sequence is not physically possible, and only a system watching location across requests notices.
Impossible travel41,200 km/h implied · sequence flagged
One set of credentials, four people on a BPO floor, four concurrent sessions. Every one of them authenticates correctly. The audit trail becomes worthless the moment you cannot say which human did which thing.
Audit trail · who did this?
09:41EXPORT customers.csv
09:42APPROVE refund
09:44CHANGE bank detail
Identity = ambiguous
A valid user, a valid password, a valid OTP — on an unmanaged device with no disk encryption and an antivirus definition file six weeks old. Authentication has no opinion about this. Context does.
alen.joseph@veno.co.inPersonal laptop · home network
Device posture
ManagedNo
Disk encryptionOff
AV definitions42 days
Access deniedidentity passed, context did not
Allow, deny or condition access on source address ranges — office egress IPs, partner and vendor networks, data-centre ranges, known-bad blocks. This is the first policy almost every organisation writes: this application is reachable from these ranges, or from a device running our agent.
Two different controls, often confused. Geo-binding ties access to a jurisdiction — this team works from these countries, and nowhere else. Geofencing draws an area on a map and restricts access to inside it. A country list is not a fence; a fence is not a jurisdiction.
Access windows attached to groups rather than individuals. Contractors on weekday business hours. Production database access only inside a change window. Administrative access out of hours permitted, but only with step-up.
The deepest signal, because there is the most to check. Managed, BYOD and unknown are three trust classes, and each earns its own depth of access. Underneath sit 25 named posture checks — antivirus presence and definition age, firewall state, disk encryption, domain membership, OS and patch level, required and forbidden processes, registry and file presence, MDM enrolment.
The organising lens. Conditions attach to roles and groups, not to people, so rules scale with headcount instead of multiplying against it. Someone changing teams changes access through group membership rather than through a ticket.
Signals combine. A policy can require an office IP and a managed device, or permit a home IP provided the device passes posture and the user clears step-up.
Geo-binding ties access to a jurisdiction — this team works from these countries, and nowhere else. Geofencing restricts access to an area you draw on a map, usually a radius around a site. A country list is not a fence, and a fence is not a jurisdiction. Most real policies use both, for different reasons.
Geo-binding
Access bound to your operating countries; every other origin denied. One rule, an immediate reduction in attack surface, and the one a regulator recognises.
Geo-binding
The same binding at state granularity, for organisations whose operations or data-handling obligations differ by state.
Geofencing
An area drawn on a map — plant floors, branch networks, secure rooms, campus deployments. Access to the operational systems happens on site, or it does not happen.
Neither is a product on its own. The value is in the stack:
Written on its own, either control is a blunt instrument. Written alongside time, device class and role, they are what let you say yes to travel and to a plant floor without saying yes to everything.
Both controls resolve location from the IP address, which is strong signal and not proof. A commercial VPN or a residential proxy can present an address inside a permitted country or near a site. Anyone selling either as an absolute control is overselling it.
Which is why it never stands alone. A request that clears the geofence still has to satisfy device binding, posture and role conditions — so a spoofed location buys an attacker one condition out of five, on a device we do not recognise, which fails on the next check.
The failure mode of every geofence is the employee who lands somewhere the policy has never seen and cannot work. Handled properly that is not a support ticket: a time-limited exception on their group with an end date, step-up on the first request from the new location, and an exception that expires by itself and appears in the audit record.
Relax the person, never the policy.
Policies that get edited for travel do not get edited back.
RBI, IRDAI and SEBI expectations about where regulated data is handled are usually met with contractual and architectural controls. Geofencing adds the enforcement layer underneath them — a demonstration that access to a regulated system happens from the geography you told the regulator it happens from, with a log entry per decision.
It supports demonstrating a control. It does not by itself discharge a regulatory obligation, and nothing here should be read as saying it does.
Pick a face. The trace names the condition that decided their request and why — then fix it, without editing the policy, and watch the same request resolve differently.
Arjun M
Regional Sales
What is holding this request back
He is at a customer site abroad. The exception goes on him with an end date — the policy is never edited.
Deny
Denied — outside the geofenced area and outside the bound countries. Location is a hard condition, not a negotiation.
Conditions met. The user does not see anything happen, which is the point — contextual access is invisible until something is off.
Session · full
Nothing happens, which is the point
Conditions partially met, or the request is unusual but plausible. The user clears one additional factor and continues. Legitimate work is not blocked; it is verified.
Multi-factor authenticationOne more factor
Verified, then continues
Identity is trusted, the circumstances are not. Access continues at reduced depth: fewer applications reachable, clipboard and download controls applied, or a browser-only session with no local data. A personal device gets the email client, not the production database.
Endpoint controlsSession · reduced
Browser-only · no local data
The request fails a hard condition — a location outside the geofence, an expired access window, a device that cannot be identified. Logged with the reason, so the help-desk call takes thirty seconds instead of thirty minutes.
Refused
Logged with the reason
Most access products offer the first and the last. The middle two are where the real work happens — they are what let you tighten policy without generating a queue of exception requests.
Most access control is a gate: it checks once, opens, and stops paying attention. A session lasts hours, and the circumstances that justified it do not hold still. Device checks are re-evaluated during the session — when a condition that was true at login stops being true, the session is narrowed, re-verified or ended, and the change is written to the log with the condition that triggered it.
One session, four decisions. The credentials never changed.
Session started · full access
And then the circumstances start moving.
| Property | RBACRole-based access control | ABACAttribute-based access control | PBACPolicy-based access control | ContextualRole plus circumstance — this page |
|---|---|---|---|---|
| Decides on | The role assigned to the user | Attributes of user, resource and environment | Centrally authored policy statements | Role plus the circumstances of the request |
| Answers | What may this role reach? | Do these attributes satisfy the rule? | Does this request match policy? | Should this request, now, from here, be honoured? |
| Re-checks after login | No | Depends on implementation | Depends on implementation | Yes — device conditions re-evaluated during the session |
| Outcomes | Allow / deny | Allow / deny | Allow / deny | Allow / step up / restrict / deny |
| Admin burden | Low, until roles multiply | High — attribute governance | Moderate to high — policy authoring | Moderate — conditions attach to existing groups |
| Fails when | A valid role is used in an invalid situation | Attribute data is stale or incomplete | Policies conflict or go unmaintained | A signal is unavailable — policy must state a default |
These are not competing purchases. Contextual access is RBAC with conditions on top and a decision that can be re-made mid-session. If you already run roles and groups in a directory, that structure is the input, not something to replace.
Outside the window: deny, not step-up
Group: contractors. Window: weekday business hours, expiring on the engagement end date. Device: managed, or passing posture. Anything outside the window is denied rather than escalated — a contractor at midnight is not a step-up case.
Every action attributable to a person
One active session per identity. A second concurrent login either displaces the first or is refused. Ends shared-login sprawl on BPO and shop floors, and makes the audit trail attributable to a person.
Managed device: full access, same user
Unmanaged device: access permitted, but browser-only, with clipboard and download controls and no local data at rest. Managed device: full access. Same user, same credentials, two different sessions.
Allowed, with step-up and session recording
Administrative roles reaching production outside business hours: allowed, with step-up MFA and privileged session recording on. The work is not blocked; it is witnessed.
Application access, never network access
Vendor group, restricted to named applications only, from a declared IP range, inside a stated maintenance window. No network access — application access. The vendor never sees anything they were not scoped to.
The policy itself is never edited
Access bound to your operating countries. Travel handled by a time-limited exception on the user's group rather than by disabling the policy — so the exception expires by itself and appears in the audit record.
Each evaluation is logged with the identity, the request context, the policy that applied, the outcome, and the specific condition that produced it. DPDP full compliance lands 13 May 2027, and RBI, SEBI and IRDAI frameworks already expect demonstrable access control with an evidence trail — “we have policies” is not an answer to an auditor.
Roles and groups come from your directory. You are adding conditions to an existing shape, not rebuilding one.
The same five signals resolve every request, and the middle answers are the ones that let you tighten policy without filling a queue with exceptions.
The four failures that pass authentication — the outlived contractor account, the impossible travel, the shared login, the personal laptop — each fail a condition instead.
Step-up and restrict mean unusual-but-plausible requests get verified or narrowed rather than refused, so tightening policy does not generate exception tickets.
Device conditions are re-checked while the session is open, so revocation is the next request getting a different answer rather than an event someone has to remember to trigger.
Tap a question — or open them all and read straight through.
Talk to us//Bring us the rule//
Thirty minutes, against your own applications. Describe the rule you have been unable to write and we will build it in the console while you watch.
Regulated, air-gapped, or on-premise? See deployment options
Finance Portal
Pune, IN09:14 · allowed
Design Library
