OVHcloud Security: Hardening Accounts, API Credentials, Networks and SecNumCloud Offers

Most OVHcloud compromises start with the account, not the server: a root NIC handle without strong second factors, an API consumer key with "*" rights on a laptop, or an OpenStack password copied into a script. OVHcloud has moved from the older NIC Admin and NIC Tech delegations to a policy-based IAM with local users, service accounts, federated users and account-level audit logs, but many accounts still run on the old patterns. This guide explains how identity and access work across the OVHcloud Control Panel, the OVHcloud API and product-level users such as OpenStack, then gives a hardening baseline for accounts, credentials, networks and logging, and notes where the SecNumCloud-qualified offers change the picture. It is written for cloud engineers, security architects and auditors who run workloads on OVHcloud. Facts are taken from OVHcloud's own documentation, checked on 8 November 2026; features and menu names change, so confirm in the console before you act. For choosing between European providers, see the Data Sovereignty and Residency Guide.

This is an independent guide from NHI Mgmt Group, based on OVHcloud's public documentation as of November 2026. It is not sponsored or reviewed by OVHcloud. Product features change, so confirm settings against OVHcloud's current documentation.

Key takeaways

• The account itself is root. OVHcloud documents that the OVHcloud account (the NIC handle such as xx1111-ovh) cannot have its rights restricted by any access policy, so it needs the strongest authentication you have and should almost never be used day to day.
• Use the right identity for each job. Local users or federated users for people, OAuth2 service accounts for machines, and product users (OpenStack, vSphere, Object Storage) only where the product needs them, each with its own owner.
• API credentials are long-lived by default. Service account client secrets have no time limit and application keys can be created without an expiry, so rotation, scoping and inventory are your job.
• Logs are off until you forward them. Audit logs, activity logs and access policy logs exist at account level but must be subscribed to a Logs Data Platform stream before you can alert on them.
• SecNumCloud is an offer, not a setting. Only named products carry the ANSSI qualification; workloads elsewhere in the same account do not inherit it, and the qualification does not configure your IAM for you.

How identity and access work in OVHcloud

OVHcloud documents several distinct identity types that can act on an account. Treating them as one "user list" is the root of most access problems.

IAM policies are built from five parts: identities (users, groups, service accounts, even another OVHcloud account), product types, resources or resource groups, actions and optional conditions. Conditions can test resource tag, resource name, product type, request IP, day of week, date and time, and a policy applies only when all its conditions are met. Actions use names such as vps:apiovh:reboot or webHosting:apiovh:get; the API console shows the IAM action for each call. A wildcard is allowed only at the start or end of an action name, for example vps:apiovh:ips/*. OVHcloud notes that ordering and billing actions are not yet available in IAM, so billing control still sits with account roles and contacts.

Two details matter for reviews. First, managed policies that OVHcloud created to convert the old NIC Admin and NIC Tech delegations appear under the OVHcloud Policies tab and cannot be edited or deleted by the customer, so check what they grant before you assume your own policies are the whole picture. Second, a policy can target another customer account, which can then delegate those rights to its own users within the scope it received. That is how managed service providers get access, and it is easy to forget once a contract ends.

Structure matters as much as policy. OVHcloud's Public Cloud best practices recommend separate projects per domain, application and environment (its example is cloud_project_finance_invoicing_qa), because projects separate resources from the rights attached to them. Production and non-production in one project means one policy mistake reaches both.

Admin roles and privileged access

Privileged access on OVHcloud has three layers: the root account, local user roles, and IAM policies that grant broad permission groups.

• Root account: enable at least two second-factor methods, keep the 10 single-use backup codes in a password manager or safe, set a backup email address that differs from the primary one, and turn on IP access restriction for the Control Panel. Use it only for tasks that genuinely need it, such as account recovery or ownership changes.
• Local user roles: OVHcloud documents UNPRIVILEGED (read-only), DEFAULT (Restricted Admin: write access to everything except user management) and ADMIN (write access including user management). Groups use None, Restricted Admin and Administrator. Give new users and groups None or UNPRIVILEGED and grant what they need through policies; keep ADMIN for two or three named people.
• Permission groups: managed groups include globalAdmin, globalReadWrite, globalReadOnly, globalTechnicalAccount and controlPanelAccess. OVHcloud advises keeping "Allow every action" (shown in the console as "Authorise all actions") disabled and selecting specific groups. Treat any policy with globalAdmin, globalReadWrite or "all actions" as privileged and review it quarterly.
• Console access as its own policy: OVHcloud recommends a separate policy for Control Panel login, which grants sign-in without resource rights. That lets you remove console access for automation identities while keeping API rights.
• Time and network conditions: use the request IP, day of week and time conditions on privileged policies so that, for example, delete actions on production work only from your bastion range in working hours.

For SecNumCloud environments, OVHcloud's own SAP on SecNumCloud concept page relays ANSSI's advice not to open the environment to external support that is not PAMS-qualified, and to use "four-eye" sessions where an internal administrator's actions are watched. That is a useful pattern for any high-value OVHcloud account. See the Phishing-Resistant MFA Guide.

Integrations, API tokens and service accounts

Automation is where OVHcloud accounts leak. The classic API flow at auth.eu.ovhcloud.com/api/createToken issues three values: the application key (AK), the application secret (AS) and the consumer key (CK). The form lets you set a validity period and a Rights field that limits methods and paths; an asterisk allows every API for that method. A token created by a local user works only where the token scope AND that user's rights both allow it, and it stops working if the person leaves and their user is removed.

Service accounts solve the "tied to a person" problem. They are OAuth2 client credentials created through /me/api/oauth2/client with flow: CLIENT_CREDENTIALS, returning a clientId and a clientSecret that OVHcloud shows once and cannot show again. Each has a URN of the form urn:v1:eu:identity:credential:xx11111-ovh/oauth2-<clientId>, which you place in IAM policies, and a script exchanges the pair for a bearer token at the OAuth2 token endpoint. OVHcloud states the pair has no time limit. Service accounts can also authenticate to the OpenStack APIs.

The local files matter too. The OVHcloud CLI and SDKs read credentials from configuration such as ~/.ovh.conf. Verify release checksums, pin versions, and keep long-lived keys off developer laptops. See the Service Account Security Guide and the API Key Management Guide.

Logging and detection

OVHcloud provides three account-level log types, each forwarded separately to a Logs Data Platform (LDP) data stream. Forwarding is free; LDP storage and use are charged at standard rates.

Useful detections from these fields:

• Root sign-in: LOGIN_SUCCESS where the user type is ACCOUNT. On a well-run account this should be rare and expected.
• Weak or no second factor: LOGIN_SUCCESS where mfaType is NONE, SMS or BACKUP_COD (the field value as documented). Backup code use should always be followed up.
• New country or IP: sign-ins from a country code you have never seen for that user, matching the access pattern of valid cloud accounts (ATT&CK T1078.004).
• Credential and policy changes: activity log paths under /me/api/oauth2/client, /me/api/application and IAM policy endpoints, which cover new service accounts, keys and policy edits (account manipulation, T1098).
• Denied bursts: spikes in unauthorized_actions_array for one identity, often a stolen key exploring what it can do.

Product logs are separate. Managed Kubernetes audit logs can also be forwarded to LDP, and the Control Panel IP restriction feature can email an alert on every unauthorised login attempt. Send all streams to your SIEM rather than relying on LDP alone. See the Cloud Logging and Audit Trail Guide.

Hardening baseline

Roll this out in order. Each phase is reversible because IAM policies and network rules can be edited or removed, but test in a non-production project first.

1. Inventory (week 1): list local users and their roles, federated groups, service accounts (GET /me/api/oauth2/client), application keys (GET /me/api/application), OpenStack users per project, cross-account policies and the managed policies under OVHcloud Policies. Give each an owner.
2. Lock the root account: security key plus a second method, backup codes stored offline, separate backup email, and Control Panel IP access restriction with the default rule set to Denied only after every legitimate public IP is listed (including mobile networks), with Alert ticked. Keep one break-glass route documented in case your IP changes.
3. Move people off shared logins: create local users or set up SAML federation, enforce 2FA for each user, and downgrade roles to UNPRIVILEGED or None with policies on top. Disable rather than delete at first, so you can roll back.
4. Replace personal API keys: create a service account per automation, scope its policy to a resource group, swap the pipeline over, then revoke the old application key. Remove any key with "*" rights and no validity period.
5. Turn on logging: subscribe audit, activity and access policy logs to LDP streams with a retention you can defend (at least a year is common for audit evidence), and forward to the SIEM.
6. Network: on Public Cloud, leave the default security group untouched (OVHcloud warns that it allows all traffic and that automated tasks can reset it), create your own groups, which allow only outgoing traffic until you add rules, and attach them to every instance. On dedicated servers, configure the Edge Network Firewall per public IP: up to 20 stateless rules at priorities 0 to 19, for example priority 0 to accept established TCP and a final deny. It is switched on automatically during a detected DDoS attack and cannot be turned off until the attack ends, and it does not support QUIC. Restrict the Managed Kubernetes API server with Authorised clients IP ranges.
7. Data: use OVHcloud KMS for keys and Secret Manager for secrets, with IAM separating key administrators from key users. OVHcloud states that its employees cannot access customer keys in OKMS.
8. Review: quarterly review of privileged policies, cross-account grants, unused service accounts and OpenStack users; remove anything without an owner.

SecNumCloud-qualified offers

OVHcloud's SecNumCloud page lists SecNumCloud-qualified offers including SNC Cloud Platform (qualification obtained in September 2026, according to the page), Managed VMware vSphere (qualified since December 2020), SAP HANA on Private Cloud and Bare Metal Pod, operated by Europe-based personnel with a commitment that data is not accessed, transferred or processed outside the EU. Qualification covers the named service, not the rest of your account: a Public Cloud project or web hosting plan in the same account is out of scope, and so are SaaS connections such as SAP BTP in OVHcloud's own SAP example. Your access model, logging and key management inside the qualified service remain your responsibility. If you are comparing sovereign options, see the Data Sovereignty and Residency Guide.

Common misconfigurations

• Root account used daily: one phished password plus SMS code gives the attacker an identity no policy can limit. Use local or federated users with policies instead.
• Application keys with "*" and no expiry: created once for a script, copied into several repositories and never revoked because nobody knows where they run. Service accounts with descriptions and owners fix the traceability.
• Credentials on developer machines: ~/.ovh.conf and openrc files with live secrets are exactly what infostealers and poisoned tools look for.
• Editing the default security group: OVHcloud warns that automated tasks can reset it, so rules added there may silently disappear and leave instances exposed.
• Forgotten cross-account and legacy delegations: a former provider's cross-account policy or a converted NIC Tech managed policy that still grants broad rights.
• Logs never forwarded: no audit or access policy log subscription, so a stolen key's activity cannot be reconstructed after the fact.

Measuring it and mapping to frameworks

Track a few numbers monthly:

• Root sign-ins: count per month, each with a ticket (target near zero).
• Second-factor coverage: share of LOGIN_SUCCESS events with mfaType U2F or TOTP (target 100% for privileged users).
• Credential age: service accounts and application keys older than your rotation period, and keys with no validity period (target zero).
• Privileged policies: number of policies with globalAdmin, globalReadWrite or all actions, and how many were reviewed this quarter.
• Owner coverage: share of service accounts, OpenStack users and cross-account grants with a named owner.

Relevant ATT&CK techniques: T1078.004 Cloud Accounts, T1552.001 Credentials In Files, T1098 Account Manipulation and, for poisoned tools, T1195.002 Compromise Software Supply Chain.

Practitioner checklist

• Root account has a security key, a second method, offline backup codes, a separate backup email and Control Panel IP restriction with alerts.
• Every person signs in as a local or federated user with their own 2FA; no shared logins.
• No local user or group holds ADMIN without a named reason; defaults are None or UNPRIVILEGED.
• "Authorise all actions" is not used outside break-glass; privileged policies use IP and time conditions.
• Each automation uses its own service account with a resource-group-scoped policy and an owner in its description.
• No application key has "*" rights or lacks a validity period; personal keys are revoked when people leave.
• Audit, activity and access policy logs are subscribed to LDP and forwarded to the SIEM, with root sign-in and NONE or SMS second-factor alerts.
• Instances use custom security groups, dedicated server IPs have Edge Network Firewall rules, and Kubernetes API servers have Authorised clients set.
• Cross-account policies and converted managed policies are reviewed quarterly.
• SecNumCloud workloads are confirmed to run on a qualified offer, with out-of-scope connections documented.

Standards and references

• OVHcloud: How to use IAM policies using the OVHcloud Control Panel
• OVHcloud: Best practices for securing and structuring Public Cloud projects
• OVHcloud: Managing OVHcloud service accounts via the API
• OVHcloud: Forwarding OVHcloud account logs to Logs Data Platform
• OVHcloud: Securing your OVHcloud account with two-factor authentication
• OVHcloud: Configure the Edge Network Firewall for Dedicated Servers
• OVHcloud: SecNumCloud
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Cloud Security Guide · Service Account Security Guide · Secrets Management Guide · Cloud IAM Review Checklist