Connectivity and trust are not the same. Good security architecture must explain why systems are allowed to communicate, not merely show that they can.
Walk into almost any architecture review meeting and you will see a familiar picture.
Applications connected to APIs. Users connecting to portals. Servers communicating with databases. Cloud platforms integrating with on-premise environments. Partners exchanging information with internal systems.
Arrows everywhere. Lines crossing each other in every direction.
The diagram looks impressive. The architecture appears complete. Everyone nods in agreement. The meeting moves on.
But often, one of the most important questions remains unanswered: Why is this connection trusted?
Because connectivity and trust are not the same thing.
Connectivity Does Not Equal Trust
A firewall rule allowing communication between two systems is not trust. A VPN connection is not trust. An API endpoint exposed to another application is not trust. A network route between cloud and data centre is not trust.
Connectivity simply means traffic can flow. Trust determines whether that traffic should be allowed to flow.
Many cybersecurity incidents do not happen because systems can communicate. They happen because systems trust something they should not trust.
A compromised service account. A stolen API token. An overprivileged application identity. An administrator account reused across multiple systems. A third-party integration with excessive permissions.
The connection itself was never the problem. The trust behind the connection was.
Every Arrow Represents A Trust Decision
Consider a simple architecture diagram:
User → Web Portal → API Gateway → Backend Application → Database
Five components. Four arrows.
Most architecture discussions focus on the technical aspects: which protocol is being used, what the bandwidth requirement is, how many transactions per second are expected, and what the expected latency is.
These are important questions. But cybersecurity architecture often asks different questions:
- How is identity established?
- How is authentication performed?
- How is authorisation enforced?
- How is the session protected?
- How are credentials managed?
- How is activity monitored?
- What happens if one component becomes compromised?
The arrow on the diagram may take one second to draw. The trust relationship behind that arrow may take months to design correctly.
Most Architecture Diagrams Show Connectivity. Few Show Trust.
Architecture diagrams are excellent at showing where traffic goes. Few explain why the receiving system should trust the sender.
User to Application
How does the application know the user is who they claim to be? Username and password? Multi-factor authentication? Federated identity? Conditional Access? Risk-based authentication?
Application to API
How does the API trust the application? API key? OAuth token? Mutual TLS? Certificate authentication? Managed identity?
Application to Database
How does the database trust the application? Shared credentials? Service accounts? Managed identities? Least-privilege access? Credential-vault integration?
Third Party to Internal Systems
How does the organisation trust the external party? Network whitelisting? Certificate authentication? Dedicated connectivity? Contractual assurance? Continuous monitoring?
The architecture diagram may show a single arrow. The security architecture behind that arrow may involve dozens of controls.
Trust Boundaries Matter More Than Network Boundaries
Traditional architecture focused heavily on network segmentation: Internet, DMZ, internal network, data centre, production environment, and development environment.
The assumption was simple. If traffic came from inside the network, it was generally trusted. If traffic came from outside, additional validation was required.
That assumption no longer holds.
Employees work remotely. Applications consume cloud services. Partners integrate directly through APIs. Developers deploy workloads across multiple environments. Software communicates with software. AI agents perform actions on behalf of users.
Machine identities now outnumber human identities in many organisations.
The modern security question is no longer: “Which network are you coming from?”
Increasingly, the question becomes: Who are you, what are you trying to do, and should you be allowed to do it?
Trust boundaries are replacing network boundaries. Identity is replacing location.
Read more...
