Why Companies Say They Want Secure IT Solutions, But Actually Do Not Want Them

Table of Contents▾

The “Paper Security” Illusion#

On paper, every larger organization wants and aims for IT security. Management surveys confirm that security is a top priority, and European regulations like NIS2 and the Cyber Resilience Act (CRA) put a strong emphasis on IT security.

Yet, every week brings serious IT incidents and data breaches that cause significant damage. In one recent example, an administrator used the password "123456", breaching the personal data of nearly 9 million Danish citizens. I have described why so little action is taken in my article We Know the Cyber Risk. So Why Don’t We Act?. Here, I want to go a step deeper.

Even when IT security is labeled a top priority by management, the reality on the factory floor looks totally different. In day-to-day delivery of software, features, and infrastructure, security is too often neglected:

Ask yourself: in your last sprint planning, sprint review, or delivery meeting… How often did you discuss if a feature is actually secure or how security is checked before deploying to production? How often in the last three to four months?

Organizations demand security from the top, but they fail to push it through on the factory floor.

---

Certification Heaven: Why ISO 27001 Should Not Be Your Priority#

When discussing security with leadership, one accomplishment comes up repeatedly: the CISO and a project team successfully renewed their ISO/IEC 27001 certification.

While renewing ISO 27001 is a solid achievement that requires documenting and fulfilling many requirements, being ISO 27001 certified does not mean your organization is secure or places an emphasis on security in daily operations.

• ISO 27001 is proof of capability: It verifies that you could follow documented policies.
• Operational security requires execution: It costs budget, developer time, and management priority, often slowing down feature delivery.

ISO 27001 proves you can do it, not that you are doing it in day-to-day operations.

---

The Project Delivery Hall of Fame (What Actually Happens)#

Major cloud vendors (such as Microsoft) invest billions to secure core SaaS business applications like Dynamics 365 and ERP systems, delivering high baseline security. However, implementation teams surrounding these platforms routinely introduce severe vulnerabilities, even in organizations that pride themselves on a “security first” mindset:

• Over-Privileged Admins: Entra ID and Azure administrators who do not fully understand security roles offering Global Admin rights just to get a task completed.
• Secret Leakage: IT personnel sending client secrets and app registration credentials via plain text email across wide distribution lists.
• Unmasked Production Clones: Multinational, billion-euro enterprises copying raw production ERP and CRM data directly into development and demo environments.
• Misplaced Configuration: Storing ERP configuration data unsafely inside their own ERP systems.
• Regulatory Compliance Violations: Attempting to run DORA-regulated, critical financial processes on low-code platforms like Power Platform without allowed controls.
• Unscreened Public Assets: Deploying public-facing portals (e.g., Power Pages) in regulated industries without conducting penetration testing prior to go-live.
• Architectural Blindness: Enterprise architects operating without an application inventory, discovering application assets reactively while running highly regulated operations.

There is a massive gap between what top management believes is happening and what actually occurs 4–5 levels down in the delivery chain. On an operational level, where security, compliance, and governance cost budget, the decision is far too often to deliver feature XYZ instead of improving security.

---

Why AI Supercharges This Risk Debt#

Deploying AI agents, chatbots, and deeply integrated AI tools into enterprise infrastructure significantly supercharges existing risk debt. Vulnerabilities and oversights can now be automatically discovered and exploited by adversaries at machine speed.

Most commercial AI tools advertise surface-level “Zero Trust” capabilities for user-facing prompts (“the agent has zero access to anything until permitted”). However, internal AI agents operating inside backend infrastructure frequently run with broad system admin rights and high-permission app registrations.

Over-privileged non-human identities are therefore one of the biggest risks today, especially because logging and tracing what they do wrong is far from trivial. These agents operate at machine speed, and your tracing, logging, and alerting need to operate at the same level. Attackers no longer need hours to find open Azure endpoints or unencrypted secrets when AI probes systems for them automatically.

---

The Architecture Takeaway#

The following list does not cover every corner of cloud security (that would be a 6,000-page, two-year read), but it gives a clear direction:

• Minimalist IaC (Infrastructure as Code) Rights: Strictly limit deployment permissions to the absolute minimum. Avoid public storage buckets and unmasked database copies.
• Zero “Unmasked” Production Clones: Never copy production databases, except in rare, isolated environments managed by seasoned professionals (such as specific GDPR-compliant setups in banking). I see this especially in Finance & Operations ERP systems, and it must be avoided at all costs.
• Short-Lived Credentials: Eliminate long-lived static secrets and API keys stored in app settings (this still seems to be common). Force workload identities to use federated credentials (such as Entra ID Managed Identities) with automatically rotated, short-lived tokens. The shorter the rotation cycle, the better.
• Hard Infrastructure Guardrails over “Prompt Filters”: Relying solely on prompt filters or system instructions is not enterprise-grade AI security, and frankly always was an intermediate solution. Enforce strict API gateways, least-privilege non-human identity scopes, and automated execution boundaries at the infrastructure level (see the Gateway Routing pattern).
• Immutable Telemetry: Implement immutable telemetry using the Event Sourcing pattern. Treat every API call, tool invocation, and administrative change as an append-only event. When an incident happens, you need instant trace logs, not post-mortem guesswork.
• Network Segmentation & Private Endpoints: Disable public network access on data stores, key vaults, and internal APIs by default whenever something is created or changed. If an AI agent or another resource needs access, route it strictly through private endpoints and VNet integration. Limit calls over the public internet wherever possible.
• Automated Checks in CI/CD: Shift security left by embedding static code analysis (SAST) and infrastructure policy checks (such as Azure Policy or OPA) directly into your deployment pipelines. If a template requests over-privileged roles or open endpoints, the build fails automatically, so the non-compliant component is never even created.
• Least-Privilege Non-Human Identities: Audit service principals, app registrations, and autonomous AI agents with the same strictness as human admins. Never grant broad reader/writer scopes at the tenant or subscription level “just to make it work”, not even in DEV or demo environments. It will bite you.

---

Closing Questions#

Let me leave you with a few architectural questions to answer for yourself:

1. In your current delivery pipeline, is security enforced at the deployment and architecture level, or is it still an administrative checklist right before go-live?
2. How wide is the gap between your organization’s ISO 27001 policies and what actually happens in your day-to-day sprint reviews? Be honest.
3. Do you actually know what permissions and API access your internal AI agents and app registrations hold right now, or are they running as unmonitored Global Admins behind the scenes?

Personally, I think it is high time to move from “We are secure and it’s our top priority” to actual priorities on the project and factory floor. Otherwise, the clock might be ticking.

---

This post reflects the personal opinion of the author and does not constitute legal advice. Organizations should consult qualified legal and compliance professionals regarding their specific situation.