Microtechx

If your organisation runs SAP, there's a good chance your security team has a significant blind spot - it is better not to wait until an incident happens...

Most enterprises have a SIEM - a centralised platform that collects security logs and alerts from across the IT environment. The problem is that standard SIEM tools are built for infrastructure: network devices, firewalls, endpoints, cloud services. They're very good at what they're designed for.

But SAP is different here.
Actions in SAP applications - are not visible at the infrastructure level. Meta information like an employee's organisational position is similarly unavailable outside the SAP application layer.

So if someone inside your organisation is slowly exfiltrating sensitive financial records through a legitimate SAP transaction, your SIEM won't see it and your firewall won't flag it. It looks like completely normal business activity - because from an infrastructure perspective, it is.

This is the problem that SAP Enterprise Threat Detection (ETD) was built to solve. And a new reference architecture from the SAP Architecture Center - contributed by Fortinet - shows precisely how ETD and enterprise SIEM/SOAR platforms can work together to give security teams full visibility across both layers.

How the two-layer approach works:
SAP ETD gathers logs from active SAP systems, pseudonymises them for privacy, enriches and normalises the data, and then loads it into SAP HANA. Predefined attack patterns - developed from ERP auditing guides, SAP's Anomaly Detection Lab, and security notes - are applied to detect potential threats and generate alerts.

Those structured, SAP-aware alerts are then forwarded to your existing SIEM or SOAR platform - Splunk, Microsoft Sentinel, FortiSIEM, or whichever tool your SOC already uses. Your security team gets the full picture: SAP application events correlated with the broader infrastructure context, with automated response playbooks able to act on either layer.

ETD understands SAP event semantics, reducing the configuration burden in the SIEM system and bridging the gap between IT infrastructure and SAP security - with licencing based on monitored users rather than unpredictable data volumes.

The result is a Security Operations Centre that no longer has to treat SAP as a separate, opaque environment. SAP threat intelligence feeds directly into enterprise security operations — and your SOC finally has the full picture.

📍If you're responsible for SAP security, enterprise architecture, or SOC operations, this reference architecture is worth reviewing carefully

Ever wondered how large enterprises run the same web app for both public users and internal employees with securety and efficiency?

There's an interesting networking pattern called Split-Brain DNS that solves this exact issue. Here is how to implement it on Azure!

Imagine you have a web application at app.contoso.com. Someone on the internet types that address and gets routed through Azure Front Door - Microsoft's global load balancer - which optimises performance worldwide, caches content at the edge, and protects the app with a Web Application Firewall.

Now imagine an employee at the same company opens a laptop connected to the corporate network and goes to the same URL. Instead of going out to the internet and back, their DNS lookup returns a completely different IP address - the private IP of the Application Gateway sitting inside the corporate network. Their traffic flows through ExpressRoute or a VPN, never touching the public internet at all.

So we get the same domain name, but two different DNS records - one for external customers via Azure Front Door, and one for internal customers pointing directly to the Application Gateway's private IP address.

Why does this matter?

For public users, you get global performance, caching, and WAF security right at the edge.
For internal enterprise users, they gain access to applications without traversing the public internet - which means lower latency, stronger data governance, and a smaller attack surface.

And critically, the architecture doesn't compromise on security for either group. To ensure traffic originates from your Azure Front Door profile, a custom WAF rule checks the X-Azure-FDID header value - making sure external traffic can't spoof its way through to your backend.

It's a clean, well-proven pattern for any organisation running hybrid-access applications - especially useful for financial services, healthcare, government, and any industry where internal and external access need to be treated very differently.

👇 Are you using split-brain DNS in your Azure environment? What's been your biggest challenge with it? Drop a comment, we would love to hear how others are handling this!

Your organisation most likely has already been breached - you just don't know it yet

That's how Advanced Persistent Threats (APTs) work.
Unlike ransomware that announces itself, or phishing that trips an alert - APTs are long-term, targeted attacks designed to infiltrate an organisation and remain hidden for as long as possible. These campaigns often unfold over weeks, months, or even years.

And they're not random. Attackers choose their targets carefully, often focusing on high-value entities like government agencies, critical infrastructure, or large enterprises.

Here's what makes APTs uniquely dangerous:
Attackers use specialised tools and tactics designed to evade traditional security controls - such as zero-day vulnerabilities, custom malware, and multi-stage operations. APTs aren't one-time events; attackers work continuously to maintain access, using a range of techniques to avoid detection and reestablish control if disrupted.

Who's doing this?
APT28 (Fancy Bear), believed to be linked to Russian military intelligence, has targeted governmental and military organisations using spear-phishing and malware. APT29 (Cozy Bear), associated with Russian intelligence services, has focused on diplomatic and governmental entities. The Lazarus Group, attributed to North Korea, has conducted operations ranging from financial theft to disruptive attacks on media and entertainment sectors.

And the scale of damage is staggering. A February 2024 cyberattack on a major healthcare IT services unit disrupted patient care and led to the theft of protected health information, impacting an estimated 190 million people.

So what actually works against APTs?
Preventing APTs requires a multi-layered approach - closing gaps across people, processes, and technology. Best practices include regular patch management, employee training to combat phishing, network segmentation with least-privilege access, continuous monitoring, and a well-practised incident response plan.

No defence is perfect, but a layered approach can significantly reduce the likelihood and impact of an APT attack - and also increase the chances you catch them early.

What is your APT defense strategy?

There is a hidden security trap in SAP multi-region failover... But we can help you avoid it

Most architects design multi-region SAP environments with geographic redundancy, load balancers, and data sync in mind. But there's one thing that routinely gets overlooked until it breaks in production: authentication.

In SAP BTP, authentication is handled by XSUAA - the Authorization and Trust Management Service - which is scoped to a specific subaccount. When you generate an OAuth token in your primary subaccount, that token only works there. The moment a failover triggers and DNS routing switches users to your secondary subaccount, those tokens are dead. Same issue with client credentials and certificates, if you're not careful.

For enterprise applications running SAP Integration Suite or Build Work Zone, this is a real operational risk...

The good news? There are clean solutions:
For SAP Integration Suite (iFlows):
- Use IAS Basic Authentication: link both subaccounts to the same IAS or custom IDP, and users authenticate seamlessly across regions
- Or use External Certificates: as long as the same certificate is registered in both primary and secondary subaccounts, failover becomes transparent to the consumer
For Build Work Zone Standard Edition:
- Keep credentials managed in IAS or a custom IDP linked to both subaccounts

Note: authentication cookies may still be tied to the primary region, meaning users could be prompted to re-enter credentials during a rare failover - easily solved with SSO

Identity design must be treated as a first-class concern in multi-region resiliency. A failover that routes traffic perfectly but breaks login is still a failed failover.

What authentication patterns have you used in your multi-region SAP setup? Drop your experience in the comments 👇

Let's imagine you gave 5 teams access to your Azure OpenAI instance. If one of them would do something they shouldn't, how would you revoke only their access?

That is actually an important question when we talk about scaling Azure OpenAI internally, so what do we do?

Azure OpenAI gives you two keys - a primary and a secondary. The secondary key exists for rotation, not for isolating clients. So when you hand that same key to your data science team, your product team, your external vendor, and two internal apps, you've created a situation where access control is essentially all-or-nothing.
Want to cut off the vendor? You're rotating the key for everyone. Want to give the product team a higher rate limit than the data science team? Not possible at the key level. Want to figure out which team is burning through your token quota? Good luck - the logs won't tell you.

To fix the problem we need to stop treating Azure OpenAI as something clients connect to directly, and start treating it as an internal service behind a gateway.

Put Azure API Management in front. Issue each client their own subscription key through the gateway. The gateway authenticates to Azure OpenAI via managed identity - no keys floating around in client configs at all. From there you get what you actually need: per-client rate limits, independent key rotation, revocation without disruption, and logs that actually tell you who's doing what.

The gateway also lets you make routing decisions based on client identity. Different teams can hit different model deployments through the same endpoint without knowing anything about the backend topology.

That is not at all exotic architecture, it is something that you would be able to operate 6 months from now on!

How are your teams handling access isolation on shared Azure OpenAI instances right now? API Management, custom gateway, or still figuring it out?

People believe NIST compliance is about passing audits - when in reality it is about controlling the risk of access breaches

There was one detail about Microsoft's explanation of NIST that caught my eye: "...security frameworks spend a huge amount of time focusing on identity, permissions, and access control, because attackers constantly exploit overexposed systems."

And that is true, most environments are way messier than teams would like to admit.

Permissions get accumulated over time, old contractor accounts stay active, admins reuse elevated privileges for convenience... Cloud platforms inherit default settings nobody reviews...

A company can technically be “compliant” while still exposing sensitive data internally.
That’s why frameworks like NIST push principles like:
- Least privilege → users only get access they truly need
- Continuous monitoring → access is reviewed constantly, not once a year
- Identity verification → trust is earned repeatedly, not assumed after login
- Configuration management → defaults are treated as risks, not conveniences

That is important, because we know that most cybersecurity problems aren't about a Hollywood-style hacker breaking through six firewalls, but about one forgotten permission sitting quietly in the environment for 18 months...

I am curious, what’s the most overlooked access control issue you keep seeing inside organizations today?

Most companies don’t fail security audits because they lack tools...

They fail because their systems can’t tell the full story👀

SAP’s reference architecture for Audit & Monitoring highlights something many organizations still underestimate:
Security without visibility is guesswork.
Modern environments spread across SAP BTP, Azure, APIs, applications, and hybrid infrastructure generate massive amounts of events, identities, and system activity. Without centralized monitoring and audit correlation, detecting threats becomes painfully slow.
That’s why modern architectures are shifting toward:
• Centralized audit logging
• Real-time monitoring and alerting
• End-to-end observability across systems
• Identity-focused tracking and accountability
• Faster incident investigation and compliance readiness

The goal is no longer just prevent vulnerabilities, it is to be able to trace, verify, respond, and prove that they exist, as in modern cybersecurity - visibility is security

The perimeter you were securing is now gone, how can your strategy keep up?

With hybrid work now the norm, traditional network security architectures are showing their age. That's why Security Service Edge (SSE) is quickly becoming one of the most important frameworks in modern cybersecurity.

Introduced by Gartner in 2021, SSE brings together cloud-based security capabilities - Zero Trust Network Access (ZTNA), Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), and Firewall-as-a-Service - into a unified model that protects your people, apps, and data no matter where they are.

Here's why it matters:

- You get consistent security enforcement for remote, hybrid, and office-based employees;
- Identity-centric access control;
- Simplified compliance with GDPR, HIPAA, PCI DSS, and more;
- Real-time threat detection powered by AI;
- And a practical path to Zero Trust architecture;

Organizations that adopt SSE are eliminating legacy complexity, reducing breach risk, and creating a seamless experience for employees.

As AI-powered threats evolve, so must our defenses. SSE isn't about the future of security - it's about the present.

Are you already exploring SSE for your organization? Drop a comment, we would love to hear how your team is approaching the transition. 👇

Most companies are racing to deploy AI agents...

But few are asking what is governing them.

Agents that operate autonomously across enterprise systems introduce risks that traditional security and compliance frameworks simply weren't built to handle: unauthorized access, opaque decisions, prompt injection, regulatory exposure.

At Microtechx, we build the architecture that makes agentic AI both powerful and compliant:

- Zero-trust agent identity & scoped authorization
- Multi-tier AI defense (foundation, supervision, automation)
- Risk classification & ethics impact assessment
- Compliance frameworks aligned with the EU AI Act and global standards

We bring together AI consulting, cybersecurity, and enterprise software expertise — so you don't have to stitch together three different vendors to get one coherent system.

Capability and compliance aren't in tension. With the right architecture, they reinforce each other.

Curious what that looks like for your environment? Let's connect.

Many organizations believe their cloud environments are compliant simply because security policies exist.

But in reality, it is hardly like that, as compliance gaps are often found each time these things happen:

• When a virtual machine is deployed outside the approved baseline;
• When some patches are missed;
• When configurations drift over time;
• When previously temporary environments become permanent;
• Or when teams lose centralized visibility across workloads;

With this, suddenly, what looked like compliance on paper becomes a real operational and security risk...

As cloud environments scale, manual compliance management no longer works - this is why modern organizations are adopting automated compliance strategies, like:

• Standardized VM configurations
• Policy-based governance
• Continuous monitoring
• Automated remediation
• Centralized security visibility

Compliance today is about maintaining security consistency across dynamic infrastructure.

Because in cloud security, even a single unmanaged virtual machine can become the weak point of the entire environment.