The current architecture is the real, observed structure of a codebase at a point in time. It shows which components exist and how they depend on one another. In governance workflows, it acts as the factual baseline for detecting drift, boundary violations, and other deviations from the design intent.
Expanded Definition
Current architecture is the as-built view of a system, not the intended design. It captures the components that are actually present, the links between them, and the dependencies that have emerged through delivery, refactoring, hotfixes, and operational work. In practice, this matters because governance decisions are only as reliable as the architecture record being used to make them.
For security teams, the key boundary is between current architecture and target or reference architecture. The former is descriptive and evidence-based; the latter is normative and directional. A codebase can be fully compliant with a design diagram and still differ materially from the current architecture if undocumented services, pathways, or integration points have appeared. That distinction is where drift detection begins.
In mature environments, current architecture is maintained from observable sources such as repositories, deployment manifests, service inventories, and dependency maps. The common misunderstanding is to treat an old diagram as current simply because it is approved. OWASP Non-Human Identity Top 10 is useful here because machine identities often reveal dependencies that architecture reviews miss.
Examples and Use Cases
Current architecture shows up wherever teams need a trustworthy baseline for control decisions, incident analysis, or design validation.
- A platform team compares the deployed microservices mesh with the documented service map to find an unexpected internal API path.
- A security architect reviews container manifests and cloud dependencies to confirm whether a data flow crosses an unapproved trust boundary.
- An engineering group uses the current architecture to verify that a refactor did not leave behind a dormant service with network reachability.
- An IAM or NHI team checks whether service accounts, tokens, and certificates still match the applications that actually use them.
- An audit or assurance workflow uses the current architecture to distinguish deliberate exceptions from undocumented changes that accumulated over time.
The practical tradeoff is that more accurate architecture views usually require more instrumentation and maintenance. A richly observed model is more useful for control validation, but it is only valuable if teams trust it enough to use it during change review and incident response.
Security Implications
When current architecture is stale, security teams can miss real attack surface. Untracked services, forgotten integrations, and shadow dependencies can create paths that bypass segmentation, logging, or approval workflows. That makes the architecture record a control input, not just documentation.
Misalignment often shows up as boundary violations that were never formally authorised, or as controls that appear effective on paper but do not cover the actual deployed path. A review may say a workload is isolated, while the current architecture still includes a legacy queue, a shared secret, or a direct administrative path into the same environment.
The consequence is not only weakened confidentiality or integrity. It also affects incident containment, because responders may trust an incomplete map and overlook lateral paths, replication links, or hidden dependencies. For NHIMG readers, the same problem applies to machine identities: if the current architecture does not reflect which non-human identities are active, privilege reviews and revocation decisions can be wrong.
Domain and Governance Relevance
Current architecture matters because governance needs an evidence base. Design intent, control intent, and operating reality often diverge, and the current architecture is the place where that divergence becomes visible. It is therefore central to change control, exception management, and boundary assurance.
In identity-heavy environments, the term becomes especially important because access pathways are often carried by services rather than people. A workload that still exists in the environment but no longer appears in the architecture record may continue to hold credentials, reach protected data, or depend on stale authorisation. That creates an ownership problem as much as a technical one.
For NHI governance, current architecture helps answer a basic question: which machines, services, and agents are actually participating in the system today? Without that answer, lifecycle controls such as inventory, rotation, revocation, and decommissioning are harder to execute correctly. The architecture view becomes the operational reference point for deciding what should still exist, what should be retired, and what requires review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Current architecture is the evidence base for identifying drift and unmanaged exposure. |
| PR.PT — Protective Technology | As-built topology determines whether protective controls actually cover live paths. | |
| DE.CM — Security Continuous Monitoring | Observed architecture depends on continuous detection of changes in components and dependencies. | |
| Recommendation — Use the current architecture to identify unmanaged dependencies that should feed risk decisions. Validate that segmentation and other protective controls match the live architecture. Continuously compare observed components against the baseline architecture and alert on drift. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Current architecture must reflect active machine identities and the systems that use them. |
| NHI-04 — Secrets and Credential Management | Architecture drift can leave credentials attached to services that no longer appear in design records. | |
| Recommendation — Maintain an accurate inventory of non-human identities that matches the live system architecture. Tie secrets and credentials to the services that still exist in the current architecture. | ||
| CIS Controls v8 | 5 — Account Management | Architecture accuracy affects whether active service accounts are known and governed. |
| Recommendation — Review active accounts against the current architecture before approving exceptions or removals. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
