When a business moves SAP Business One off a server in the back office and into a professionally managed cloud environment, the natural assumption is that security has just become someone else's problem. “The cloud provider handles security now” is a common line heard in the handover meeting. It's only partly true.  Cloud infrastructure removes a long list of jobs from an internal IT team: racking servers, patching an ageing operating system, worrying about a failed disk at 2am. What it doesn't remove is the business's own responsibility for who gets access to the system, what they can see and change inside it, how endpoints connecting to it are protected, and how internal processes govern sensitive data. Microsoft's own cloud security guidance is explicit on this point: customers always retain responsibility for their data, their identities and their accounts, while responsibility for the underlying infrastructure shifts depending on whether the service is IaaS, PaaS or SaaS.  This article sets out where that line actually sits for SAP Business One running in the cloud, using SAP's own shared responsibility thinking and Microsoft's cloud security model as the reference points, rather than treating “cloud security” as a single, undifferentiated promise.

Is SAP Business One Cloud Secure? 

Quick answer  SAP Business One can be deployed with a wide range of security controls covering authentication, authorisation, encryption, database protection and backups. In a cloud environment, however, security is a shared responsibility. The hosting provider or SAP partner protects and operates the infrastructure, while the customer still needs to manage users, permissions, business data, endpoints and internal access policies. 

What Does “Shared Responsibility” Mean for SAP Business One Cloud? 

Cloud security for SAP Business One doesn't work on a model where the provider is 100% responsible and the customer simply logs in. It works more like a stack: cloud infrastructure, the SAP environment itself, the partner operating that environment, and the customer's own controls, all contributing to the overall security position at the same time.  SAP's own cloud security model divides responsibility between SAP, customers and the public cloud provider. SAP is explicit that customers retain responsibilities including solution administration, user access, data access and certain threat-detection and response activities, even once the underlying infrastructure has been handed to a cloud provider.  Who is responsible for SAP Business One Cloud security? Is the cloud provider responsible for all ERP security? These are the two questions almost every business asks at the start of a cloud project, and the honest answer to both is: partly, and it depends which layer of the stack you mean.

Security Area	Cloud/Hosting Layer	SAP/Solution Layer	SAP Partner/Managed Service*	Customer
Physical data centre	Primary	—	—	—
Compute/storage infrastructure	Primary	—	Operational oversight	—
SAP B1 installation	—	Product	Primary/Shared	—
Updates & patches	—	Product updates	Primary/Shared	Governance
Backup operation	Infrastructure support	—	Primary/Shared	Requirements/validation
User creation	—	Functionality	Support	Primary
User permissions	—	Functionality	Support	Primary
Business data	Infrastructure protection	Application controls	Operational support	Primary ownership
Endpoint security	—	—	Advisory	Primary
Integration security	Shared	APIs/features	Shared	Shared
Security monitoring	Shared	Shared	Shared	Shared

Exact responsibilities depend on the chosen hosting and managed-service agreement. That caveat matters, because SAP Business One deployment models vary considerably: some businesses host on infrastructure they manage themselves, some use a hyperscaler such as Microsoft Azure, and some hand the whole environment to an SAP partner under a managed-service contract. The table above describes a typical pattern, not a fixed rule for every deployment. 

What Security Does the Cloud Provider Handle? 

Moving down the stack to the infrastructure layer: for an Azure-hosted environment, Microsoft describes the cloud provider as responsible for the underlying physical infrastructure, physical data centres, the physical network and the physical hosts the workloads run on. Responsibility for everything above that varies by service model. 

Physical data-centre security 

Physical access control, facility security, environmental protection (power, cooling, fire suppression) and the physical hardware itself all sit with the cloud provider at this layer. 

Physical networking 

Routers, switches and the underlying networking infrastructure connecting the data centre to the outside world are the provider's responsibility, not something a customer configures or audits directly. 

Physical hosts 

The physical servers on which cloud workloads actually run, including their maintenance and replacement, belong to the provider. 

Availability infrastructure 

Depending on the architecture chosen, compute, storage, network and availability configuration can sit wholly or partly with the provider, with the specific split depending on the service model in use.  Worth being precise about: it's inaccurate to say “Azure secures your entire SAP Business One environment.” Azure, or any equivalent hyperscaler, secures its own portion of the technology stack. Application configuration, user access and business data remain separate responsibilities that sit elsewhere. 

What Security Controls Does SAP Business One Provide? 

Authentication 

SAP Business One supports its own native authentication and can also work with Identity and Authentication Management capabilities. Current SAP documentation describes support for SAP Business One's own authentication, Microsoft Windows domain authentication, OpenID Connect (OIDC), and external identity providers. OIDC in particular allows an organisation to sign in with an existing identity-provider account and inherit that provider's own security features, such as two-factor authentication, rather than creating and managing yet another separate username and password.  Does SAP Business One support SSO? Yes. SAP Business One supports identity and authentication mechanisms, including SSO-related capabilities through external identity providers via OIDC, with the exact configuration available depending on the version and environment in use.

How Does SAP Business One Control User Access? 

Authentication and authorisation get used almost interchangeably in everyday conversation, but they answer two different questions. Authentication asks: who are you? Authorisation asks: what are you allowed to do, now that we know who you are?  SAP Business One provides mechanisms to restrict database access and prevent end users from reaching database credentials directly, which keeps authorisation decisions inside the application layer rather than leaving them exposed at the database.  In practice, this plays out around real job functions. A salesperson typically needs customers, quotations and sales orders, but has no operational reason to see payroll information, sensitive financial configuration or system administration settings. A warehouse employee typically needs inventory, goods receipt and picking functions, but doesn't need financial reports or customer credit controls. Getting this mapping right, department by department, is what turns “access control” from a security slide into something that actually reduces risk day to day. 

What Security Responsibilities Still Belong to the Customer? 

This is where a lot of the real risk sits, because these are the areas a hosting provider or SAP partner genuinely cannot own on the customer's behalf. 

1. User lifecycle management. Who gets an account, and when.
2. Permissions. What each user can see and change once they have one.
3. Employee offboarding. What happens, promptly, when someone leaves.
4. Privileged accounts. Who holds administrator-level access, and why.
5. Endpoint security. Laptops and workstations connecting to the ERP still need protecting.
6. Credential practices. Avoiding shared logins, weak passwords and unnecessary admin accounts.
7. Internal business controls. The same person ideally shouldn't be able to create a supplier, enter an invoice and approve the payment without any separation of duties.
8. Data governance. Who can export customer data, view financial data, change master data or download reports.

Microsoft's own guidance lists customer data, identities and user accounts, and configurations and settings among the areas customers continue to own across every cloud service model, which lines up closely with how SAP frames customer responsibility for SAP Business One specifically. 

How Is SAP Business One Data Encrypted? 

Is SAP Business One data encrypted?

It can be, across several layers, though exactly which layers are active depends on how the database and infrastructure are configured.  For SAP Business One running on SAP HANA, SAP documents support for encrypting data volumes, redo logs, data backups and log backups, each independently switchable and each protecting a slightly different part of the system. SAP Business One also documents SSL encryption for communication between the server and clients in relevant configurations, protecting data while it's actually moving across the network rather than sitting on disk.  Two concepts are worth keeping separate here. Encryption at rest protects data where it's stored, the database files, the backup media. Encryption in transit protects data while it travels between systems, the client and the server, or two integrated applications. 

Data State	Example	Relevant Protection
At rest	ERP database	Database/storage encryption
In transit	Client ↔ server	TLS/SSL
Backup	Database backup	Backup encryption
Credentials	Authentication	IAM/access controls

Are SAP Business One Cloud Backups Automatic? 

Not automatically in the sense most people assume. The honest answer is: it depends on the hosting and managed-service configuration in place.  SAP's own administrator guidance says businesses should develop a backup strategy based on their own requirements and data volumes, and recommends regular application-database backups rather than treating a single default schedule as sufficient for every business. Before accepting “we take backups” as a complete answer, it's worth asking how often backups are taken, where they're stored, whether they're encrypted, how long they're retained, whether copies are geographically separated, how quickly they can actually be restored, and when the last restore test took place.  An important distinction: backup is not the same as disaster recovery, and neither is the same as high availability. A backup is a recoverable copy of data. Disaster recovery is the process and infrastructure required to restore business operations after a serious failure. High availability is architecture designed to reduce service interruption in the first place. A business can have excellent backups and still have no real disaster recovery plan, because nobody has ever tested how long a full restore actually takes. 

Who Is Responsible for Testing Backups? 

A backup job reporting “successful” doesn't, by itself, prove the business can actually recover from it. Restore testing, database integrity checks, and two specific figures, Recovery Point Objective and Recovery Time Objective, are what turn a backup routine into an actual recovery plan.  RPO, Recovery Point Objective: how much recent data the business could tolerate losing.  RTO, Recovery Time Objective: how long the business could tolerate the ERP being unavailable.  If backups run every 24 hours, losing up to nearly a day's transactions may theoretically be possible, depending on the architecture and recovery arrangements in place. For plenty of businesses that's a manageable risk. For an e-commerce operation processing hundreds of orders a day, a day's worth of lost transactions is very unlikely to be acceptable, which is exactly why RPO and RTO need to be numbers the business has actually agreed to, not assumptions nobody has tested. 

Does Moving SAP Business One to the Cloud Automatically Make It More Secure? 

No. Cloud infrastructure removes certain risks tied to poorly maintained local hardware and gives access to infrastructure controls most SMEs couldn't build themselves. But weak permissions, weak passwords, poor endpoint security, unsecured integrations, careless configuration and absent internal controls can all still create real vulnerabilities, regardless of how well the underlying infrastructure is run.  SAP itself recommends treating security as a whole-system-landscape issue rather than limiting security policy to SAP Business One in isolation, which is a useful way to frame the whole topic: the ERP application is one part of a larger environment, and the weakest part of that environment, not the strongest, tends to determine the overall risk. 

What Are the Biggest SAP Business One Cloud Security Risks SMEs Should Watch? 

None of these are exotic. Most are ordinary operational gaps that accumulate quietly over time.  Excessive user permissions: Too many users carrying more access than their role actually needs.  Dormant accounts: Former employees, old contractors or unused integrations still holding active logins.  Shared user accounts: Weak accountability, since nobody can say for certain who actually did what.  Poorly secured endpoints: The cloud environment can be well run while the employee laptop connecting to it isn't.  Unsecured integrations: Every API and integration expands the attack surface, not just the storefront or app it connects.  Unpatched components: Add-ons, middleware and dependencies need their own lifecycle management, not just the core ERP.  Weak backup strategy: Backups that have never actually been restored and tested.  Misconfiguration: Cloud security still depends heavily on correct configuration, not just on being “in the cloud”. 

How Should You Secure SAP Business One Integrations? 

Modern SAP Business One environments rarely stand alone. Magento, Shopify, WooCommerce, CRM platforms, banking connections, document management systems, payment services, shipping carriers and assorted third-party applications are all common connections.  SAP Business One ↔ API / Service Layer / Integration Layer ↔ External System  Each connection in that chain raises its own questions: how is it authenticated, how are API credentials stored and rotated, what permissions does it actually hold, is the traffic encrypted, is activity logged, how are errors handled, and are there exposed endpoints nobody's reviewed in months.  Can a secure SAP Business One system still be exposed through an insecure integration? Yes. Overall security posture is determined by the broader system landscape a business has built, not by the ERP application in isolation. A perfectly configured SAP Business One instance connected to one carelessly secured integration is still a perfectly exposed system.

What Happens When an Employee Leaves the Company? 

This is where good intentions in a security policy meet the reality of a busy HR process. A reasonable ERP offboarding sequence looks like this: 

1. Disable the SAP Business One account 

1. Revoke remote access 

1. Remove identity-provider access 

1. Revoke VPN access 

1. Remove administrative privileges 

1. Rotate shared or API credentials if exposed 

1. Review integrations owned by the employee 

1. Recover company devices 

1. Review recent activity where appropriate 

Skipping any single step here tends not to cause an incident immediately. It just leaves a door unlocked that someone eventually finds. 

How Often Should SAP Business One Access Rights Be Reviewed? 

The principle worth holding onto: users should have the access necessary to perform their responsibilities, not simply the access that was easiest to grant when the account was first created. Reviews are worth triggering after employee role changes, department transfers, new integrations going live, add-ons being implemented, organisational restructuring, departures, and security incidents. Beyond those trigger points, periodic reviews should follow the organisation's own risk and compliance requirements rather than a universal fixed frequency invented for the sake of having one. 

What Should an SAP Partner Manage in a Cloud Environment? 

An SAP partner or managed-service provider can potentially handle infrastructure setup, SAP installation, database administration, updates and patches, monitoring, backup operation, restore assistance, security configuration, firewall configuration, integration support, performance monitoring and incident troubleshooting. The exact division always depends on the specific service agreement in place; no two managed-service contracts split these identically.  What does an SAP Business One cloud partner actually manage? In most arrangements, the technical operation of the environment, the infrastructure, patching, backup operation and monitoring, while the customer retains ownership of user access decisions, business data governance and internal process controls. The specifics should always be confirmed in writing rather than assumed from the sales conversation.

What Security Questions Should You Ask an SAP Business One Cloud Provider? 

1. Where is our SAP Business One environment hosted? 

1. Who manages the operating system? 

1. Who applies security patches? 

1. How frequently are backups performed? 

1. Are backups encrypted? 

1. Where are backups stored? 

1. How long are backups retained? 

1. When was the last restore test? 

1. What is the expected RPO? 

1. What is the expected RTO? 

1. Who monitors the environment? 

1. How are administrator accounts controlled? 

1. How are integrations secured? 

1. What happens during a security incident? 

1. What security responsibilities remain with our company? 

SAP Business One Cloud Security Checklist for SMEs 

Identity 

• Individual user accounts 

• Strong authentication 

• SSO/identity-provider strategy where appropriate 

• Prompt employee offboarding 

Access 

• Least privilege 

• Role-based permissions 

• Limited administrator accounts 

• Regular access review 

Infrastructure 

• Supported software 

• Security updates 

• Firewall/network controls 

• Monitoring 

Data 

• Encryption strategy 

• Data access controls 

• Sensitive-data policies 

Backup 

• Defined backup schedule 

• Backup encryption 

• Retention policy 

• Restore testing 

• RPO/RTO documented 

Integrations 

• Secure APIs 

• Protected credentials 

• Logging 

• Credential rotation 

• Unused connections removed 

Endpoints 

• Updated devices 

• Endpoint protection 

• Controlled remote access 

SAP Business One Cloud Security Responsibility Matrix 

This is the article's signature reference, built with four columns and a graded scale, Primary / Shared / Customer-controlled / Depends on agreement, rather than simple ticks and crosses, because a binary yes/no genuinely misrepresents how these responsibilities are split in most real deployments. 

Security Control	Cloud Provider	SAP Partner	Customer
Data centre	Primary	—	—
Hardware	Primary	—	—
Network	Primary	Shared	—
Operating system	Depends on agreement	Primary	Governance
SAP Business One	—	Primary	Customer-controlled
HANA/SQL database	Shared	Primary	Governance
Patching	Depends on agreement	Primary	Governance
Firewall	Shared	Primary	—
Backup	Depends on agreement	Primary	Customer-controlled
Monitoring	Shared	Primary	—
User accounts	—	Shared	Primary
Permissions	—	Shared	Primary
Endpoint	—	—	Primary
Integrations	—	Shared	Shared
Business data	—	Shared	Primary
Incident response	Shared	Shared	Shared