Access Control Standard

An access control standard specifies the technical requirements that authentication mechanisms, authorisation models, and session management must satisfy. This standard establishes minimum requirements for all systems that store, process, or transmit organisational data. Individual systems may impose stricter controls based on data sensitivity or regulatory obligations, but no system may operate below these baselines.

The standard applies to all systems under organisational control, including cloud services, on-premises infrastructure, and third-party platforms where the organisation maintains administrative responsibility. Systems managed entirely by third parties fall under contractual security requirements rather than this standard directly, though vendor assessments must verify equivalent controls exist.

Authentication

The process of verifying that an entity is who or what it claims to be, typically through credentials, tokens, or biometric factors.

Authorisation

The process of determining what actions an authenticated entity is permitted to perform on specific resources.

Principal

Any entity that can be authenticated and granted permissions: human users, service accounts, automated processes, or federated identities.

Privileged access

Access rights that permit modification of security controls, system configuration, or other principals’ permissions.

Authentication requirements

Authentication mechanisms must verify principal identity before granting any system access. The strength of authentication required scales with the sensitivity of accessible data and the privilege level of the account.

Password requirements

Passwords remain acceptable as a single authentication factor only for systems classified as low sensitivity with no access to personal data. All other systems require passwords combined with additional factors or passwordless authentication methods.

Password complexity rules requiring specific character classes (uppercase, lowercase, numbers, symbols) reduce effective entropy by constraining user choices and encouraging predictable substitution patterns. Length provides greater security than composition requirements. A 12-character password without complexity rules drawn from a 95-character set provides approximately 79 bits of entropy, compared to 52 bits from an 8-character password with complexity requirements where users predictably select “Password1!”.

Systems must implement the following password controls:

Multi-factor authentication requirements

Multi-factor authentication (MFA) combines two or more independent verification methods from different categories: something the principal knows (password, PIN), something the principal possesses (hardware token, registered device), or something the principal is (biometric). Using two methods from the same category does not constitute MFA.

MFA methods vary in resistance to interception and phishing attacks. The following table ranks methods by security strength:

Privileged accounts require phishing-resistant MFA methods. SMS and email-based one-time passwords are unacceptable for any account with administrative capabilities or access to high-sensitivity data, as these channels are vulnerable to SIM swapping, call forwarding attacks, and email compromise.

Push notification authentication must implement number matching, where the authenticator displays a number that the user must enter at the authentication prompt. This control prevents MFA fatigue attacks where adversaries repeatedly trigger push notifications until the user approves.

Passwordless authentication

Systems should support passwordless authentication through FIDO2/WebAuthn where technically feasible. Passwordless authentication eliminates the password as an attack vector entirely, relying on cryptographic proof of possession of a registered authenticator. The authenticator may additionally require biometric or PIN verification for user presence.

Passwordless authentication satisfies MFA requirements when the authenticator itself requires multi-factor verification (for example, a hardware key with PIN, or a platform authenticator with biometric).

Authorisation model

Authorisation determines what actions authenticated principals may perform. The authorisation model must implement least privilege, granting only the minimum permissions necessary for each principal’s legitimate functions.

Role-based access control

Role-based access control (RBAC) assigns permissions to roles, then assigns principals to roles. A role represents a job function or responsibility within the organisation. Principals inherit all permissions of their assigned roles, and nothing more.

+------------------------------------------------------------------+
|                    RBAC STRUCTURE                                |
+------------------------------------------------------------------+
|                                                                  |
|  +-------------+     +-------------+     +-------------+         |
|  | Principal   |     | Principal   |     | Principal   |         |
|  | (User A)    |     | (User B)    |     | (Service X) |         |
|  +------+------+     +------+------+     +------+------+         |
|         |                  |                   |                 |
|         v                  v                   v                 |
|  +------+------+     +-----+-------+     +-----+-------+         |
|  | Role:       |     | Role:       |     | Role:       |         |
|  | Finance     |     | Finance     |     | Backup      |         |
|  | Analyst     |     | Manager     |     | Service     |         |
|  +------+------+     +------+------+     +------+------+         |
|         |                  |                   |                 |
|         v                  v                   v                 |
|  +------+------+     +-----+-------+     +-----+-------+         |
|  | Permissions:|     | Permissions:|     | Permissions:|         |
|  | - View      |     | - View      |     | - Read all  |         |
|  |   reports   |     |   reports   |     |   files     |         |
|  | - Run       |     | - Run       |     | - Write to  |         |
|  |   queries   |     |   queries   |     |   backup    |         |
|  |             |     | - Approve   |     |   storage   |         |
|  |             |     |   payments  |     |             |         |
|  +-------------+     +-------------+     +-------------+         |
|                                                                  |
+------------------------------------------------------------------+

Figure 1: RBAC model showing principals assigned to roles, which carry specific permissions

Role design must follow these requirements:

Attribute-based access control

Attribute-based access control (ABAC) evaluates access requests against policies that consider attributes of the principal, resource, action, and environment. ABAC provides finer-grained control than RBAC alone and handles dynamic conditions such as time, location, or device posture.

Organisations may implement ABAC as a layer above RBAC, where role membership is one attribute among many. A policy might grant access when the principal has the “Finance” role AND the request originates from a managed device AND the current time falls within business hours AND the resource’s data classification does not exceed the principal’s clearance level.

ABAC policies must be documented, version-controlled, and tested before deployment. Policy changes require review and approval equivalent to code changes.

Privileged access requirements

Privileged accounts require additional controls beyond standard authentication and authorisation. Compromise of a privileged account threatens the entire environment, not merely the data that account directly accesses.

Privileged account types

Privileged access controls

Privilege escalation

Privilege escalation paths must be explicitly defined and controlled. No principal should obtain elevated permissions except through documented, auditable mechanisms.

Implicit privilege escalation through misconfigured permissions, overly broad service accounts, or unmonitored automation scripts constitutes a control failure requiring immediate remediation.

Service account requirements

Service accounts authenticate automated processes, applications, and system integrations rather than human users. Service accounts require distinct controls because they cannot respond to MFA prompts, often require persistent credentials, and their activity patterns differ fundamentally from human users.

Service accounts must not have interactive logon capability except where specifically required for the service function, in which case interactive logon must be restricted to designated service hosts.

Access review requirements

Access reviews verify that granted permissions remain appropriate. Without periodic review, permission accumulation occurs as principals change roles, projects conclude, and temporary access persists beyond its intended duration.

Review outcomes must be documented with the following information: reviewer identity, review date, accounts reviewed, decisions made (retain, modify, revoke), and justification for retained access. Reviewers must attest that they have verified each access grant remains necessary.

Identified violations must be remediated within defined timeframes:

Session management requirements

Sessions maintain authentication state after initial verification, eliminating the need to re-authenticate for each request. Session controls balance usability against the risk of session hijacking or abandoned sessions providing unauthorised access.

Re-authentication must be required for sensitive operations regardless of session validity:

Federated authentication requirements

Federation allows principals authenticated by one identity provider to access resources in another organisation’s systems without maintaining separate credentials. Federation reduces credential proliferation but introduces dependencies on external identity providers and requires trust relationships to be carefully scoped.

Implementation by system type

The following table provides lookup reference for how requirements apply to common system categories. Specific systems may require stricter controls based on risk assessment.

Exceptions

Exceptions to this standard require documented approval from the information security function and the system owner’s management chain. Exception requests must include:

• Specific requirement(s) to be excepted
• Business or technical justification
• Compensating controls implemented
• Risk assessment with residual risk acceptance
• Review date (maximum 12 months)
• Accountable individual

Exceptions do not exempt systems from review and audit. Excepted controls must be re-evaluated at each review date, and exceptions renewed only if the original justification remains valid and no compliant alternative has become available.

See also

• Information Security Policy
• Identity and Access Management
• Multi-Factor Authentication
• Privileged Access Management
• Access Reviews and Recertification
• User Onboarding
• User Offboarding