Cohesion

Expanded Definition

Cohesion describes how tightly related the responsibilities inside a component are. In software and security architecture, a cohesive module, service, policy set, or control function tends to do one thing well, with fewer hidden side effects and less confusion about ownership. Low cohesion usually means the component has become a catch-all, mixing unrelated logic, workflows, or exceptions that are harder to reason about and govern.

For NHIMG, the useful boundary is practical rather than academic: cohesion is not the same as size. A large component can still be cohesive if its parts support one clear purpose, while a small component can still be poorly cohesive if it mixes concerns. In architecture reviews, this distinction matters because teams often mistake “simple to explain” for “well designed.” In security-sensitive systems, the clearer test is whether the component can be changed, tested, or approved without forcing unrelated changes elsewhere.

That boundary is especially visible in policy code, workflow engines, and identity tooling, where a single object may combine validation, routing, escalation, logging, and exception handling. When those concerns remain entangled, the design becomes harder to verify and easier to misconfigure.

Examples and Use Cases

Cohesion appears wherever teams break a system into services, modules, or policy boundaries. The same term is used in design reviews, control mapping, and maintainability discussions, but the practical meaning stays consistent: keep related responsibilities together and unrelated ones apart.

• A privileged access workflow that only handles approval logic is more cohesive than one that also performs account discovery, credential rotation, and incident triage.
• An API gateway policy that centralises authentication decisions can be cohesive, while one that mixes auth, rate limiting, routing, and transformation may be harder to govern cleanly.
• A detection rule set is more cohesive when each rule covers one threat pattern or event class instead of trying to represent several unrelated behaviours in a single rule.
• A machine identity lifecycle process is easier to audit when issuance, rotation, revocation, and ownership are separated into related but distinct functions rather than buried in one oversized workflow.
• NIST SP 800-53 Rev 5 Security and Privacy Controls is useful when cohesion is being applied to security control structure, because control families and control enhancements help teams separate concerns more cleanly.

The main trade-off is that extreme decomposition can create fragmentation. Cohesion improves when separation reflects a real responsibility boundary, not when every step is isolated just for its own sake.

Security Implications

Low cohesion is a design smell with direct security consequences. When one component carries unrelated responsibilities, it becomes harder to test exhaustively, harder to review for privilege boundaries, and easier to change in ways that create unintended access or data exposure. A code path that handles authentication, configuration, and business logic in one place also increases the blast radius of a defect, because one weakness can affect multiple functions at once.

In practice, poor cohesion often shows up as ambiguous ownership. Teams may not know whether a failure belongs to application engineering, IAM, operations, or security, so issues linger longer than they should. That delay matters in access control, secrets handling, and audit logging, where unclear responsibility can produce silent drift rather than an obvious outage.

Well-cohesive components make security review more precise. Reviewers can ask whether the unit does the minimum necessary job, whether its inputs and outputs are narrowly defined, and whether a failure in one function can be contained without destabilising others. The observable symptom of poor cohesion is usually not one dramatic incident, but recurring confusion, duplicated logic, and fragile change management.

Domain and Governance Relevance

Cohesion matters in governance because it shapes how confidently an organisation can assign control ownership, measure compliance, and prove that a component is operating within scope. In identity and security operations, cohesive design helps keep authentication, authorization, logging, and recovery responsibilities distinct enough to audit without guesswork.

For NHI governance, the concept becomes even more practical. Workload identities, service accounts, tokens, and certificates often fail operationally when too many lifecycle tasks are bundled into one process. A cohesive machine-identity design separates issuance, privilege assignment, renewal, and revocation so each step can be governed and reviewed on its own terms. That makes ownership clearer and reduces the chance that a hidden dependency will keep an old credential alive after it should have been removed.

In broader cybersecurity programmes, cohesion also supports more reliable policy mapping. When a control objective has one clear responsibility, it is easier to assign evidence, test effectiveness, and detect drift. Poor cohesion obscures those boundaries and makes governance depend on tribal knowledge instead of explicit design.

Related resources from NHI Mgmt Group

• Semantic Cohesion