How to Design Security That Is Strict Yet Explainable

Modern cybersecurity can no longer rely solely on static rules. The same user, device and application may represent different levels of risk depending on where the connection originates, the situation in which the user is working and the type of data involved.

Security decisions must change with the context

This is why adaptive security is becoming increasingly important. A system should not decide only once whether a user can be trusted. It should continuously evaluate a range of signals:

• user behaviour,
• the condition and vulnerability of the device,
• the sensitivity of the operation being performed,
• the location of the connection,
• the type of network,
• the current operational and security context.

This is consistent with the principles of Zero Trust, but it also raises a practical question: how can different signals be combined into a decision that people can understand?

Why a simple average is not enough

Simple scoring models often add together or average different types of risk. This is computationally convenient, but it may conceal important asymmetries.

A cautious user may be working from a vulnerable device. Conversely, a secure device may be used by someone behaving unsafely in an inappropriate context. When everything is averaged into a single number, information about why the situation is problematic may be lost.

Separate risk vectors

We therefore work with the idea of separate risk vectors. Instead of relying on a single opaque score, the system monitors three basic groups of signals independently.

• The behavioural vector describes user decisions, habits and ways of working.
• The technical vector reflects the condition, configuration and vulnerability of the device.
• The contextual vector determines whether the situation is genuinely significant from a security perspective.

These components should not simply cancel one another out. The aim is to preserve information about the source of the risk and enable the system to explain which part of the situation led to an intervention.

The example of public Wi-Fi

This problem is particularly visible in public Wi-Fi environments. A user may behave cautiously while their device has an insecure configuration. Or the device may be properly secured while the user connects in an environment with a higher likelihood of attack.

A well-designed security architecture should preserve and explain these differences. It should not merely report that the overall risk has reached a particular numerical value.

Adaptive security is also a question of governance

Security decisions are not purely technical. They must also be proportionate, auditable and defensible.

When a system blocks access, requires additional authentication or activates a protective measure, the organisation should understand why. The explanation should not be that “the model decided”, but that a specific combination of behaviour, device condition and context exceeded a reasonable threshold.

Explainability has practical value

Explainability is not merely an academic requirement. It helps system administrators, auditors and users.

• A system administrator can better understand what is happening and where the risk originates.
• An auditor can assess the proportionality and consistency of decisions.
• A user can receive a clearer and more specific intervention.

Instead of displaying a generic warning, the system might explain that the user is connecting through an open network, without active protection, while accessing a more sensitive service.

Strict only where strictness is justified

The aim is not to create a system that is always more restrictive. The aim is to create one that is strict where strictness is justified and restrained where intervention would create unnecessary friction.

Good adaptive security is therefore not merely a question of algorithms. It is also a question of responsible governance, explainability and respect for the real environment in which users operate.