A developer connects a customer portal to cloud storage. An automation exports a report overnight. A deployment pipeline updates an application. Each needs access, and each may continue running long after the person who configured it has moved on.
For a business owner, these connections are easy to overlook because they do not resemble employee accounts. Yet they deserve the same question you ask about a staff member: what can this identity access, and who is responsible for it?
A recent Azure incident puts that question in focus
Microsoft’s report published on 25 September 2026 describes Azure activity associated with Storm-3168, linked to JADEPUFFER. Two compromised service principals were used for discovery, destructive operations and credential collection. The observed incident occurred in early June; the September date is the report’s publication date, not the attack date. [1]
Microsoft recorded more than 100 storage-account deletion attempts in roughly seven minutes. Some deletion attempts were blocked by protective controls. It did not observe a ransom note or confirm successful data exfiltration in the activity described. [1]
The initial compromise route remains unconfirmed. A service-principal secret had previously appeared in a public GitHub issue and remained in its edit history after removal, but Microsoft could not confirm that this secret enabled the attack. [1]
This is a documented compromise of a customer environment, not evidence that every Azure tenant is affected. For Malaysian SMEs, it is a useful reason to review the identities behind applications and automation before an incident forces that review.
Why an application needs a different control
Microsoft describes workload identities as including applications, service principals and managed identities. These identities help software access resources without a person signing in for every task. A managed identity can remove the need for developers to handle credentials for supported Azure scenarios. [2]
Your employee MFA policy does not automatically solve this problem. Microsoft’s workload Conditional Access documentation states that workload identities cannot perform MFA. Its service-principal policies require Workload Identities Premium licensing, and managed identities and multitenant applications are outside that policy coverage. [3]
Our recommendation is to treat application access as an operating responsibility, with an owner, an agreed purpose and a review date. “The developer set it up” is a starting point for discovery; it is not a complete ownership model.
Start with one business workflow
Consider a hypothetical distributor whose portal uploads delivery documents. The integration was given broad permissions during testing, and the same configuration reached production. Nothing looks wrong to the users: uploads still work. The management question is whether those permissions remain justified.
Ask the technical owner to explain which resources the integration needs, which operations it performs and where its credentials are maintained. Compare those answers with the permissions actually granted. Record any unexplained difference as an action, with an owner and deadline.
Make changes in a controlled way. Narrowing permissions without understanding dependencies can break a live process. Use a representative test, agree a maintenance window where necessary and document how to reverse an unsuccessful change. Security improvement should leave the business with a working system and clearer accountability.
Reduce secrets without assuming the job is finished
Where the workload supports it, assess whether a managed identity is suitable. For external workflows such as GitHub Actions, Microsoft documents workload identity federation: the workload exchanges a trusted external token for access to authorised Microsoft resources, reducing reliance on stored application secrets. [2][4]
These mechanisms change how access is authenticated. They still require sensible permissions and a carefully configured trust relationship. Ask for evidence of a successful authorised operation and an unsuccessful operation outside the intended scope. Keep that evidence with the implementation record.
If a secret has been exposed publicly, hiding the original text does not make the credential safe. Microsoft advises revoking or rotating exposed credentials and investigating their historical use. [1] Coordinate replacement with the application owner so dependent services are updated and validated.
Turn the review into a useful management record
A small company does not need a lengthy presentation to start. A short register can show the application, business purpose, technical owner, resources accessed, credential approach and next review date. Prioritise identities touching customer records, production applications or recovery systems.
At the next service review, request three concrete outputs: unresolved permission exceptions, evidence that agreed changes were tested, and the person responsible for responding to suspicious activity. Review recovery responsibilities separately; the people maintaining an application should know whom to contact if restoration is needed.
The useful outcome is fewer unexplained permissions and a team that can act when something changes. If your application identities have never been reviewed, start with one important workflow this week and expand from there.
To discuss a review of your cloud environment and security priorities, contact AXO Technologies.
Sources
[1] Microsoft Security Research, published 25 September 2026: Storm-3168: Agentic-driven cloud attacks using compromised service principals.
[2] Microsoft Learn, updated 19 August 2025; checked 5 October 2026: Managed identities for Azure resources.
[3] Microsoft Learn, updated 24 March 2026; checked 5 October 2026: Conditional Access for workload identities.
[4] Microsoft Learn, updated 9 April 2025; checked 5 October 2026: Workload identity federation concepts.
