What You Are Exposing

You clicked that button because some part of you already suspects this is true. Architecture documentation contains exactly the intelligence an attacker needs to plan a precise, efficient breach. Not a theoretical breach. A specific one, informed by the technical detail you wrote down to help your own team.

This page walks through what your documentation reveals, category by category. Each section shows the information as your team sees it and then as an attacker reads it.

Service Topology

What your team sees: A diagram of 14 microservices, their communication protocols, and which ports they use. Useful for onboarding new engineers, planning capacity, and debugging production issues.

What an attacker reads: A complete map of lateral movement paths. Every arrow on that diagram is a route from one compromised service to the next. The central services with the most connections are the highest-value targets. The protocol annotations tell the attacker whether to use HTTP exploits, gRPC vulnerabilities, or message queue injection. No network scanning required.

Database Landscape

What your team sees: A record of database technologies and versions. PostgreSQL 15.2 for the primary datastore, MongoDB 6.0 for the document store, Redis 7.0 for caching. Useful for upgrade planning, licence management, and support contracts.

What an attacker reads: Three search queries against a CVE database. Each product name and version number maps directly to a list of known vulnerabilities. PostgreSQL 15.2 has specific CVEs. MongoDB 6.0 has different ones. The attacker does not need to fingerprint your databases through network probing. You have already provided the exact information they need.

Your documentation also records which services connect to which databases. This maps the path from a compromised application to the data it can access. The attacker knows that if they compromise the reporting service, they reach the PostgreSQL instance. If they compromise the content service, they reach MongoDB. Each connection is an attack path.

PII Mapping

What your team sees: Entity-relationship diagrams with data classification annotations. The Customer entity stores full name, date of birth, national insurance number, and bank account details. The Order entity links to Customer and contains payment card tokens. Data flow diagrams show PII moving from the customer-facing API through the customer service into the primary database.

What an attacker reads: A treasure map. The exact table names. The exact field names. Which fields contain the highest-value data. Which database holds them. Which service has access. Which data flows carry PII between components.

Without this documentation, an attacker who gains database access must examine hundreds or thousands of tables. They must guess which fields contain useful data. They must trace data flows through trial and error. Your entity-relationship diagram eliminates all of that work. You classified the data to support GDPR compliance. That same classification tells the attacker exactly what to steal and where to find it.

API Surface

What your team sees: API documentation with endpoints, authentication requirements, request/response schemas, and rate-limiting configuration. A reference for developers integrating with your services.

What an attacker reads: A categorised list of attack targets.

Integration Points

What your team sees: Documentation of message queues, webhook endpoints, event buses, and third-party integrations. Essential for understanding how data moves through the system and for debugging async workflows.

What an attacker reads: The weakest links. Message queues often have weaker authentication than primary APIs. Webhook endpoints accept inbound requests from external services, sometimes with minimal verification. Event buses route messages between services with little per-message authentication.

Your integration documentation identifies these components, their authentication mechanisms, and their access patterns. An attacker who cannot breach your primary API may find that the RabbitMQ instance backing your async workflows has default credentials, or that the webhook endpoint accepting payment notifications performs only basic signature verification.

Security Controls and Governance

What your team sees: Risk assessments, threat models, and security control documentation. Evidence of good governance. Proof that the organisation takes security seriously.

What an attacker reads: A gap analysis, written by the target, describing their own weaknesses.

If your threat model documents WAF rules as the primary SQL injection mitigation, the attacker knows to research WAF bypass techniques. If your risk assessment marks a remediation as "planned for Q3", the attacker knows the system is currently vulnerable and will remain vulnerable for a known period. If your security control documentation lists what defences exist, it implicitly reveals what defences do not exist.

Version History

Cloud documentation platforms store version history by design. Every edit is preserved. Every previous state is recoverable. This is usually presented as a feature.

For an attacker, version history is an intelligence timeline. They can diff versions to see when security controls were added, which reveals when they were absent. They can identify windows of vulnerability: the three months between when a service was deployed and when its authentication was tightened. They can find previous architecture states that reveal legacy components still running in production but removed from current documentation.

40 Minutes

Consider a financial services organisation. Their architecture documentation is stored in a cloud wiki. An attacker gains read access - through a compromised account, a forwarded link, or a misconfigured sharing permission.

Here is what happens next.

No scanning. No probing. No guesswork. Forty minutes of reading replaced weeks of active reconnaissance. Every step is informed by documentation that was written to help the development team.

The question is not whether to document

Architecture documentation is essential. Without it, teams cannot onboard new engineers, plan capacity, manage risk, or maintain regulatory compliance. The answer is not to stop documenting.

The question is where that documentation lives and who can access it.

If your architecture documentation is stored in a cloud platform with a web interface, it is accessible to anyone who can authenticate to that platform, or anyone who compromises an account that can. If it is stored in a tool with an API, it is accessible to any process that can obtain a valid token. If it is shared via links, it is accessible to anyone who receives or intercepts that link.

Military organisations classify network topology as SECRET. Banks treat system architecture diagrams as Confidential - Internal. Nuclear facilities restrict control system documentation to named individuals with security clearance.

Enterprise IT stores structurally identical information in tools designed for collaboration and sharing.

The Structural Fix

The fix is not better access controls on the same cloud platforms. The fix is structural: remove architecture documentation from cloud-hosted tools, web interfaces, and network-accessible storage entirely. Store it as files on the local filesystem. Encrypt at rest. Version-control in git. Access only through filesystem permissions or SSH keys. Publish only what specific audiences need, through controlled publishing targets, to local files or internal servers.

The documentation an attacker cannot reach is documentation that is not on the network at all.

This is not a feature. It is an architectural decision that shapes everything else: model-first design works because the model lives locally. Governance by graph works because the intent graph is never exposed to external services. Security is the foundation that makes the rest possible.

What to do about it

The white paper Architecture is Reconnaissance examines the full threat model: where architecture documentation lives today, why cloud platforms and self-hosted wikis both increase the attack surface, how version history creates a persistent intelligence record, and what a local-first, offline-capable alternative looks like.

Read the full white paper - a detailed analysis of how architecture documentation becomes reconnaissance intelligence, with a framework for evaluating your current exposure.

Download NeoArc Studio - architecture documentation that stays on your machine. No cloud storage. No web interface. No API endpoints. No attack surface beyond physical access to the device.