Access is the realised ability of a subject to reach, view, use, enter or interact with a resource under stated conditions.
Public web pages, staff-only systems, confidential records, temporary project folders, privileged administrator consoles and controlled physical spaces all differ in who can access them, what kind of access is possible, how long it lasts and what evidence proves the access was legitimate.
Quick answer: how should access be categorised?
- Audience: public, internal, partner, restricted, privileged?
- Subject: person, role, team, service, device or system?
- Resource: data, application, place, function, document or capability?
- Action: view, use, enter, modify, export, administer?
- Condition: identity, device, location, time, approval, risk state?
- Duration: standing, temporary, session-based or event-bound?
- Channel: physical, local, remote, API, portal or delegated path?
- Evidence: what proves access was granted and used?
- Revocation: how can access be removed?
- Audit: what activity must remain traceable?
This page complements How to Categorise Permissions. A permission is an authorisation rule; access is the actual state in which a subject can reach or use a resource. A permission can exist without successful access, and access can sometimes occur through a defect even when permission was not valid.
Access is not permission
Permission describes what should be allowed. Access describes what can actually be reached or used at a given moment.
Access is not ownership
A borrower, employee, customer or service account may access a resource without owning it.
Public access requires no special membership
Public information or spaces are broadly reachable, though ordinary law, safety rules and technical limits can still apply.
Internal access is limited by organisational membership
Internal does not mean harmless. Some internal resources may still contain material that should not be shared with every employee or team.
Restricted access narrows the eligible subject set
Need-to-know, role, clearance, contract, project or regulatory conditions can restrict who may reach a resource.
Privileged access enables consequential control
Administrator, root, financial approval, publishing and deletion access can alter systems or records and therefore deserve stronger authentication, review and logging.
Temporary access should expire
Contractor, emergency and project-specific access should end automatically or trigger review when the reason for access disappears.
Conditional access depends on context
Trusted device, network, location, time window, risk score, approval or resource label can determine whether access is permitted at the moment of request.
Role-based access groups permissions by function
Role-based access control gives users access because they occupy a defined role. This is efficient when business functions are stable and permissions map cleanly to roles.
Attribute-based access uses subject, resource and environment attributes
Department, sensitivity label, device state, location and time can combine to create more granular decisions than role alone.
Direct access and delegated access differ
A subject may act directly or through another service, agent, role or proxy. Delegation should preserve whose authority is being exercised.
Physical access and logical access need separate controls
Entering a server room and logging into a server are different access domains even when they protect the same asset.
Read access and write access are not equivalent
Visibility, modification, export, approval and administration should be separated because consequence differs.
Standing access creates exposure
Long-lived access is convenient but increases the time during which credentials, role drift or forgotten accounts can create risk.
Just-in-time access narrows the exposure window
Access can be activated for one task or period and then removed, reducing unnecessary standing privilege.
Access pathways should be observable
Authentication logs, session records, entry logs and service receipts help distinguish attempted access from successful access and use.
Access reviews should examine actual reachability
A policy may say that access is removed while cached credentials, inherited groups or legacy interfaces still allow entry. Effective access should be tested rather than assumed.
Access should follow sensitivity
More sensitive resources generally justify narrower audiences, stronger authentication, tighter export controls and more complete audit evidence.
Access can fail closed or fail open
When identity or policy cannot be evaluated, a system may deny access or permit continued operation. The safer choice depends on the harm of false denial versus false permission.
Revocation is part of access design
High-consequence access should be removable quickly and should invalidate active sessions or delegated credentials where necessary.
A practical access record
- access ID;
- subject;
- resource;
- action class;
- audience class;
- permission source;
- conditions;
- channel;
- start and expiry;
- authentication method;
- privilege level;
- audit requirements;
- revocation state;
- last review;
- version.
The deeper idea
Access is where abstract policy becomes real reachability. It is the point at which identity, permission, sensitivity, context and infrastructure meet.
To categorise access well is to know who can actually reach what, what they can do there, under which conditions, for how long, and what evidence proves the access was legitimate and revocable.
Final answer
Categorise access by audience, subject, resource, action, condition, duration, channel, privilege, evidence, revocation and audit. Keep access separate from permission and ownership, test effective rather than merely intended access, and narrow privilege as resource sensitivity rises.