Current Architecture

Expanded Definition

Current architecture is the factual, point-in-time view of what a system actually contains and how those components depend on each other. In NHI and IAM governance, it is distinct from intended architecture, which describes how the environment was designed to work. The current architecture is used to detect drift, shadow dependencies, orphaned service accounts, and trust boundaries that no longer match operational reality.

Definitions vary across vendors on whether current architecture is captured from source code, deployment manifests, runtime telemetry, or all three. In practice, NHI security teams treat it as the most defensible baseline for enforcing least privilege, validating secret exposure paths, and checking whether an AI agent or service account has gained unintended execution authority. That makes it especially useful when paired with Zero Trust and configuration review processes described in the NIST Cybersecurity Framework 2.0. The most common misapplication is treating the design diagram as current architecture, which occurs when teams ignore live dependencies introduced by CI/CD changes, hotfixes, and third-party integrations.

Examples and Use Cases

Implementing current architecture rigorously often introduces discovery and reconciliation overhead, requiring organisations to weigh accuracy against the cost of continuous inventory maintenance.

• A security team compares runtime service-to-service calls against the intended trust model to find new paths created by a recent release.
• An NHI program uses the current architecture to locate service accounts that still have access after an application module was retired.
• An incident responder reviews live dependencies to determine which API keys, certificates, or tokens could be used to reach a compromised workload.
• A platform team maps deployed containers and agents to verify whether any autonomous software entity has access outside its approved boundary.
• An architecture review references the Ultimate Guide to NHIs alongside runtime evidence to understand where NHI controls are most often broken.

Used well, current architecture becomes a shared evidence layer for governance, operations, and audit. It also aligns with identity assurance and access validation concepts in NIST Cybersecurity Framework 2.0, especially when organisations need to prove that deployed access paths match policy.

Why It Matters in NHI Security

Current architecture matters because NHI risk is rarely confined to design-time assumptions. Real environments accumulate stale secrets, hidden integrations, and permission creep, and those changes often expose attack paths that a static diagram would miss. NHIMG research shows that 97% of NHIs carry excessive privileges, which makes an accurate current architecture essential for finding where those privileges are actually usable and where they should have been removed. The same baseline helps identify whether tokens, certificates, and service accounts are still attached to active workloads or lingering in decommissioned ones. In Zero Trust programs, current architecture is the evidence layer that shows whether trust decisions are being enforced in practice rather than merely declared in policy. The Ultimate Guide to NHIs is a useful reference for understanding why visibility and lifecycle control are inseparable from this baseline.

Organisations typically encounter the cost of current architecture only after a breach, audit failure, or failed migration, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How does NHI security relate to Zero Trust Architecture?
• Why do non-human identities complicate zero trust architecture?
• What does AI model abuse reveal about the current NHI threat surface?
• Why do AI access keys complicate zero trust architecture?