Iain Dickson, Technical Fellow and Cyber Practice Lead at Leidos Australia 
Across Defence and government, the traditional model of cyber security built around networks, boundaries, and segregation is no longer enough.
Today, information constantly moves across systems, domains, partners, and suppliers, which means traditional ‘castle and moat architecture’ security assumptions, based on a strong exterior defence, simply don’t hold.
With remote work, a mobile workforce, and cloud services, there is no longer a single ‘castle’ to defend. Data is everywhere, and so are the threats. It’s this operating context that is driving many IT leaders to make the shift to data-centric security.
The primary objective of these organisations is Mission Assurance – having absolute confidence that your critical systems and information will work exactly when needed, even if you are under attack. Achieving this depends on getting the right information to the right people, at the right time, with confidence in its integrity, control, and provenance. When that becomes the requirement, the security boundary has to move closer to the data itself.
While that sounds good in theory, it can be a high-maintenance approach with real downsides, including a dependence on high-quality tagging, more complex governance, and harder integration with legacy systems.
Why organisations are moving this way
At its core, Attribute-Based Access Control (ABAC) changes how access decisions are made. Instead of relying mainly on network location or static group membership, it evaluates attributes such as classification, nationality, organisation, and mission need, moving the access decision closer to the data.
It enables fine-grained, real-time control at the data level. Access decisions are made at the point of use – file, record, or message – rather than at the perimeter. That means data can remain in place while still being made available to the right people under the right conditions.
It enables collaboration across environments without constant duplication. Instead of moving or replicating data across networks – and inheriting the delay, overhead, and risk that comes with that – ABAC allows access to be granted logically, based on attributes and policy.
This is not theoretical. It is already being engineered in secure, cloud-based environments where identity, policy, and data-layer controls are brought together into a single operating model.
The challenges are real and often underestimated
ABAC assumes that data is consistently and correctly labelled. In reality, that’s a non-trivial problem. It requires standardised schemas, governance across organisations and tooling to enforce tagging at scale.
Integration is also a significant challenge. Many existing systems were not built with ABAC in mind. They rely on coarse-grained access models or embedded assumptions about networks and domains. Retrofitting ABAC into these environments is often complex and sometimes infeasible without architectural change. Many vendors will say they can do this, but in practice, that often means placing a gateway in front of a legacy environment rather than integrating policy deeply into the platform itself.
There’s also the reality that ABAC rarely exists in isolation. In practice, most environments end up with a hybrid model that includes ABAC layered over existing RBAC controls. Designing that interplay properly is also non-trivial, and poorly implemented hybrids can introduce inconsistency or ambiguity in access decisions.
There is also a more practical problem that is often underestimated: business roles rarely map neatly to access policy. Titles and organisational structures do not always reflect what people actually do, what decisions they support, or what information they genuinely need. Roles and responsibilities can be fluid. If those realities are not understood up front, attribute models become either too coarse to be useful or so complicated that they are hard to govern. Good policy depends on the business doing the work to define legitimate access needs with enough precision.
What this means in practice
While ABAC offers many benefits, it is not a silver bullet. The real challenge is how to operationalise it credibly end-to-end across policy, platforms, and within real delivery constraints. This requires a deep understanding of the problem space and operational environment it will be operating in.
A useful current problem to think about this is through the concept of Information Sharing within the AUKUS Treaty. The AUKUS treaty has reinforced that information sharing is not a supporting activity on the side; it is an enabling condition for advanced capability, and it becomes difficult very quickly when policy, classification, access models, and technical environments do not align. Lessons learned are hard won through real delivery experience – about the shape of the problem and what it takes to operate across organisational and national boundaries.
That requires more than policy language. It requires identity, attributes, enforcement, tagging, governance, and platform design to work together as one system.
Experience delivering secure, cloud-based environments shows that ABAC only works as part of a cohesive system, which means having federated, attribute-rich identity; centralised policy enforced consistently; data-layer enforcement in the platform; and applications that natively support ABAC or can be adapted to it.
Bottom line
ABAC and data-centric security are not interesting because they are new terms. They matter because modern operations depend on secure, timely access to data across boundaries that older security models were never designed to handle.
The organisations that will succeed are not the ones that describe ABAC most confidently. They are the ones that treat it as an architectural shift, understand the problem honestly, and invest in operationalising it across real data, real roles, and real systems.
Want to see more stories from trusted news sources?Make Cyber Daily a preferred news source on Google.