Security as an Architectural Property

Security is often treated like an item on a feature list: something you plan, implement and tick off, ideally toward the end, when the system is otherwise finished. That notion is the reason so many systems are insecure even though nobody forgot about security. Because security isn't a feature; it is a property of the whole — of how the parts fit together, whom they trust, what they are allowed to do. A property of the whole can't be added at the end without touching the whole.

This document treats security as an architectural property: as something you design in from the start, not bolt on at the end. It is deliberately framework-neutral and deliberately defensive — it describes how to build systems that withstand misbehavior, not how to attack systems. It names no tool and no number. The principles apply regardless of any technology, because they are about structure, not about a product.

1. Why security isn't a feature

A feature is something you add: a field, a flow, a capability that was missing before. Security can't be added that way, because it doesn't sit in one place but in how all the places relate to each other. It emerges from whom a part trusts, what rights it has, what it accepts and what it exposes. A system is exactly as secure as the weakest of these relationships — and no feature bolted on afterwards changes that, because the weakness lies in the structure, not in a missing capability.

This leads to the basic stance: security belongs at the beginning, in the design, because the decisions that determine it — boundaries, rights, trust — are design decisions. Anyone who wants to "add" it at the end discovers that it would have to sit everywhere at once and can therefore be added cleanly nowhere. Thinking about security late means retrofitting it expensively and incompletely; thinking about it early means building it in almost incidentally.

Diagram: bolted on afterwards, security is a shell with gaps; designed as a property, it runs through the entire system. Only the second holds.

Trade-off. Thinking about security from the start costs effort before the system delivers any value at all — it feels like a detour, but it is the only way to get security in the first place.

Cost. The design becomes more careful and slower, because at every boundary and every right you ask the security question instead of postponing it.

When we decide differently. For a throwaway prototype without real data and without access to the outside world, a full security design is overkill; as soon as the system touches real data or real users, it is indispensable.

2. Threat modeling as a design activity

Before you can protect a system against misbehavior, you have to know what can go wrong — and that is a question you ask during design, not after the first incident. Threat modeling isn't anything mysterious: it is the habit of asking, for every part of the system, who could harm it, what it has to protect and what would happen if an assumption doesn't hold. You deliberately think for once like someone who isn't well-disposed toward the system — not to attack it, but to find the weaknesses before someone else does.

The value of this activity lies in making the invisible visible. Many security holes aren't bugs in the code, but overlooked assumptions in the design: that an input will be correct, that a caller will be authorized, that a part of the system will be trustworthy. Threat modeling brings these assumptions to light while they are still cheap to change. It is therefore not a phase and not a document, but a way of thinking that you weave into the design.

Trade-off. Thinking deliberately about threats costs time in the design and the willingness to ask uncomfortable "what if" questions while everyone wants to finish the system.

Cost. The exercise requires experience and discipline; it can't be worked off as a checkbox, but has to be meant seriously to achieve anything.

When we decide differently. Where a part obviously has no data worth protecting and no access from outside, you skip the deep analysis; attention goes to the boundaries where the foreign meets your own.

3. The principle of least privilege

The single most effective principle of secure design is simple: every part of a system gets exactly the rights it needs for its task — and no more. A service that only needs to read must not write. A part that only needs a slice of the data sees only that slice. Access granted for a task ends with it. The reason is sober: what a part isn't allowed to do, it can't cause even if it is itself compromised or faulty. Least privilege limits the damage before it happens.

The principle works because it contains the consequences of a failure without having to prevent the failure. You can't close every hole, but you can make sure that a single hole doesn't open up the entire system. A system in which every part may do everything is as secure as its most vulnerable part; a system of least privilege keeps the damage where it occurs. That is why least privilege isn't a configuration detail but a design stance: you distribute power sparingly, because power you haven't distributed can't be abused.

Trade-off. Least privilege buys containment with more care in the design — you have to determine for each part what it really needs instead of generously allowing everything.

Cost. Finer-grained rights take more effort to design and maintain than blanket ones; convenience gives way to precision.

When we decide differently. In a small, closed system whose parts fully trust each other anyway and which has no external boundary, fine-grained rights are overkill; their value grows with the number of parts and the proximity to the outside world.

4. Defense in depth

No single safeguard always holds. A check can be overlooked, an assumption can fail, a part can break down. Defense in depth is the stance of never relying on a single line of defense, but layering several one behind the other, so that the failure of one is caught by the next. If the outer check becomes porous, the inner one holds; if an assumption about the caller is wrong, least privilege limits the damage. Security doesn't come from one perfect wall, but from several imperfect ones that hold together.

Diagram: not one wall, but several. If the outer layer falls, the next one holds — security through redundancy, not perfection.

Trade-off. Multiple layers buy resilience with more effort and some redundancy — you build protection that feels superfluous in the normal case.

Cost. Each layer is itself something you design, understand and maintain; too many or poorly chosen layers increase complexity without increasing security.

When we decide differently. Where what needs protecting is minor and the potential damage small, a single, well-chosen line of defense is enough; depth pays off where a failure would cause serious damage.

5. Secure defaults

Most systems are used the way they are configured by default — not the way they could be configured in the best case. That is why the default is one of the most consequential security decisions: is the secure state the standard you end up in without doing anything, or do you first have to actively establish it? Secure defaults mean that, when in doubt, the system closes rather than opens — that you have to consciously opt into risk instead of consciously opting out of it. What is closed by default stays closed for most people.

The reason is human reality: configuration gets forgotten, postponed, misunderstood. A system that is only secure if someone configures it correctly is insecure for most. A system that is secure as long as nobody changes anything is secure for most. The secure default shifts the burden from the user, who would have to think of everything, to the design, which decides correctly once. That isn't distrust of the user, but forbearance toward them: you build the system so that the convenient path is also the secure one.

Trade-off. Secure defaults buy security for the many at the cost of some inconvenience for the few who consciously need the risk and have to unlock it first.

Cost. Determining the secure default and sticking to it requires deciding in the design against the lure of convenience, which is often the more open option.

When we decide differently. In a closed environment operated by experts, where the restrictive default only slows things down, the standard may be more open; the broader and less known the user base, the stricter it should be.

6. Trust at the boundaries

Security is decided at the boundaries — where the foreign meets your own. The most important rule is: nothing that comes from outside is trustworthy in and of itself. Every input, every call, every message from beyond your own boundary is checked before it is allowed to have any effect — not out of distrust toward the individual sender, but because you don't know all the senders and one of them might not mean well. What counts as safe inside a boundary must first become safe at it.

That presupposes that you know your boundaries in the first place: where does what you control end, and where does what you can only observe begin? Every such line is a trust boundary, and at each one the same care applies as when designing a public API — the check of what may come in is part of the contract. A system that doesn't know its boundaries unknowingly trusts things it doesn't know; a system that knows them decides deliberately at each one what it lets in.

The four load-bearing principles in summary — each a design stance, not a configuration:

Trade-off. Checking at every boundary buys security with effort and some friction — every check is work and can briefly hold up a legitimate call.

Cost. Knowing the boundaries and checking consistently at each one requires a discipline that is easily sacrificed to convenience in daily work, "because the caller is known anyway."

When we decide differently. Inside a clearly closed boundary, where all parts are subject to the same trust and are operated together, you don't have to check at every inner line; full care applies to the boundaries facing outward.

7. The human and operational side

The best design doesn't protect against neglect in operations. Security has a side no diagram shows: how secrets are handled, how fixes are applied, the dependencies you drag along and the people who operate the system. A secret lying around in plain text nullifies every access control. A known hole in a dependency that you don't close promptly is an open door you know about yourself. The person pushed to hurry is the most vulnerable point of any system.

This side demands less genius than consistency. Secrets must be protected and kept out of the code; dependencies must be monitored and their known holes closed promptly; access is revoked when it is no longer needed; and processes must be designed so that the secure path is also the easy one, so that nobody bypasses it under pressure. Security is therefore not a one-time achievement, but ongoing care — a system is only as secure as it is operated today, not as it was once designed.

Trade-off. Operational security buys lasting protection with lasting work — monitoring, updating, maintenance that is never finished.

Cost. This work produces nothing visible and therefore constantly competes with the next feature for attention and time.

When we decide differently. Here, too: where there is neither data worth protecting nor access from outside, the upkeep may be leaner; as soon as both are in play, it is non-negotiable.

8. The honest limits

An honest document about security also says what security is not: a guarantee. There is no absolute security, and anyone who promises it is selling a feeling, not a system. Security is risk management — deliberately reducing the likelihood and consequences of misbehavior to an acceptable level, knowing that a residual remains. This honesty isn't an admission of weakness, but the prerequisite for smart decisions: only those who know that security is never finished and never complete invest it where it protects the most.

This also leads to a trade-off that has to be named openly: security and convenience often pull in different directions. Every check, every boundary, every revoked right costs a bit of ease of use. The art isn't building the maximum of security — that would be unusable — but the right measure for the specific risk: strict where the damage would be large, lenient where it is small. Security is therefore not an absolute, but a trade-off you make deliberately and in proportion to the risk.

Trade-off. Understanding security as risk management means living with residual risk instead of expecting a guarantee — that is less comfortable than the illusion of completeness.

Cost. Finding the right measure requires judgment about likelihood and damage that can't be delegated to a rule.

When we decide differently. Where the potential damage is existential, the balance shifts strongly toward security, even at the expense of convenience; where it is minor, convenience may prevail.

9. Typical mistakes

The recurring patterns where secure systems fail — almost all are variants of treating security as a feature rather than a property:

• Pushing security to the end and wanting to "add" it to the finished system, where it would have to sit everywhere at once.
• Taking assumptions for facts — that an input is correct, a caller authorized, a part trustworthy — instead of checking them.
• Handing out rights generously, so that a single hole opens up the entire system instead of the damage being contained.
• Relying on a single line of defense that has nothing behind it when it fails.
• Making the insecure the default and hoping someone will configure it correctly later.
• Unknowingly trusting what comes from outside because you don't know your boundaries.
• Storing secrets in plain text and leaving known holes in dependencies open.
• Making secure processes so cumbersome that people bypass them under pressure.
• Promising absolute security and thereby replacing the honest trade-off with a false promise.

10. Decision checklist

Clarify the following, in order, before and during the design of a system:

• Property, not feature? Has security been considered from the start — or planned as a later add-on?
• Threats considered? Has it been asked for every part who could harm it and what it has to protect?
• Least privilege? Does every part get only what it needs for its task — and nothing beyond that?
• Defense in depth? Is there, behind every line of defense, another one that catches its failure?
• Secure default? Is the secure state the standard you end up in without doing anything?
• Boundaries known and checked? Are the trust boundaries named, and is what may come in checked at each one?
• Secrets and dependencies? Are secrets protected, dependencies monitored, known holes closed promptly?
• Secure path the easy one? Are processes designed so that nobody bypasses the secure path under pressure?
• Proportion instead of absolutes? Is security proportionate to the risk — strict where the damage would be large, lenient where it is small?

Anyone who can answer these questions has built security into the design — not hung it on the finished system.

FAQ

Can't you add security later? Only incompletely and expensively. Security doesn't sit in one place, but in the relationship of all parts — in boundaries, rights, trust. These are design decisions; changing them at the end means touching the entire system. Considered early, security gets built in almost incidentally; considered late, it gets retrofitted laboriously and with gaps.

What is the single most effective principle? Least privilege. If every part gets only what it needs for its task, a single hole can't open up the entire system — the damage stays where it occurs. The principle doesn't prevent every failure, but it limits the consequences of every failure, and that is often worth more.

Does threat modeling mean we have to think like attackers? Only to the extent that you find the weaknesses before someone else does. It isn't about attack techniques, but about the habit of asking, for every part: what could go wrong here, who could trigger it, what would the consequence be? These questions bring overlooked assumptions to light while they are still cheap to change.

Is there such a thing as absolute security? No. Security is risk management, not a guarantee — deliberately reducing likelihood and consequences to an acceptable level, knowing that a residual remains. Anyone who promises absolutes is selling a feeling. This honesty is the prerequisite for deploying security where it protects the most, instead of spreading it evenly.

How much security is enough? As much as the risk demands — strict where the potential damage is large, lenient where it is small. The maximum would be unusable, because security and convenience often pull in different directions. The art is the appropriate measure, chosen deliberately and differently depending on the damage, not the highest conceivable protection everywhere.

Is security a design topic or an operations topic? Both, inseparably. The property is created in the design — boundaries, rights, defaults — but it is preserved or lost in operations: through how secrets are handled, how promptly known holes are closed, how dependencies are maintained. A well-designed system that is poorly operated is insecure; that is why security belongs on the architecture table and in the routine of operations.

Further reading

• API design for long-lived systems — the contract surface as a trust boundary where inputs are checked.
• Reversibility over prediction — containing damage and keeping decisions reversible, as a form of defense in depth.
• Observability is architecture — you can only defend against what you notice; observability is the prerequisite for seeing misbehavior.
• OIDC — a concrete building block of access and identity at the boundary.

It is grounded in the Batunet Engineering Method: design for failure, keep the uncertain small, draw boundaries deliberately, secure by default.

Closing engineering principle

Security isn't a state a system reaches, but a property it has or doesn't have — and it only has it if you built it in before it was needed. You can build a wall around a finished house, but you can't lay a foundation under an inhabited one; security is foundation, not wall. That is why the decisive moment for a system's security isn't the incident, but the design — long before anyone thinks of attacking it. A system that only thinks about security after the first incident thinks too late. Good engineering thinks beforehand, calmly and proportionately, and builds in the property that can't be retrofitted.

You don't bolt security onto a finished system — you build a system that is secure because it was conceived that way. Everything else is a wall with gaps that you only see when it counts.