Core Web App

Prior to 2.45.0, IP allow list controls didn't apply to the API. As of 2.45.0, they do, requiring customers to whitelist every IP their API integrations (CIPP, Halo, ScalePad, etc.) call from. Request: add a setting to exclude the API from IP allow list enforcement, so customers can opt back into the pre-2.45.0 behavior if they don't want IP restrictions applied to API traffic.

Problem Once a user is logged in, viewing/revealing a password does not require a second Duo/2FA challenge. That increases risk if a session is left open, shared, or read by browser/AI tooling that can interact with an already-authenticated page. Desired behavior Optional account (or role) setting: “Require step-up MFA to reveal passwords.” When enabled, revealing a password (and ideally copying the plaintext value) requires a fresh Duo push or TOTP confirmation before the secret is shown. Why it matters Adds a practical control against shoulder-surfing, unattended sessions, and automated tools that can click “reveal” on an authenticated browser. Acceptance criteria Admin toggle (default off) Applies to asset passwords and vault passwords Works on web (mobile if feasible) Failed/cancelled MFA does not reveal the password Continue to audit-log successful password views Reasonable re-auth window optional (e.g. don’t re-prompt every reveal within N minutes)—admin configurable

Problem When Microsoft SSO (SAML) is enabled, users who sign in via SSO are signed into Hudu immediately after a valid SAML assertion. Hudu Duo and Hudu TOTP are not prompted on that path. Customers who want SSO + Duo push on every login (web and mobile) cannot get that from Hudu Duo today—MFA must be enforced only at the IdP (e.g. Entra Conditional Access / Duo for Microsoft). Desired behavior Add an optional account setting such as “Require Hudu Duo / 2FA after SSO.” When enabled, after a successful SAML login Hudu should still send the user through Duo (or TOTP if Duo is off), the same way password login does today. Why it matters Many MSPs require Microsoft SSO and still want Duo as the consistent second factor inside Hudu on web and mobile, without relying only on Entra configuration. Acceptance criteria Admin toggle: enforce Duo/2FA after SSO (default off to preserve current behavior) Works for web and mobile SSO flows Password-login Duo behavior unchanged Portal users / exempt groups follow existing SSO exemption rules where applicable

I have a scoped API key for a company (e.g. 152) that allows me to query all assets for that company. How can I retrieve all relations for that asset (e.g. 867) that belongs to that company? My API key does not have permission to retrieve these relations - receiving a 401 unauthorized {"error":"Permissions scoped to company"} --- echo "== Confirm asset 867 belongs to the allowed company (152) ==" curl -s " https://mycompany.huducloud.com/api/v1/companies/152/assets?page=1&page_size=1000 " -H "x-api-key: $Hudu__ApiKey" | grep -o '"id":867,"company_id":[0-9]*' echo echo "== Now query /relations filtered to that exact asset, same scoped key ==" curl -s -i " https://mycompany.huducloud.com/api/v1/relations?fromable_type=Asset&fromable_id=867 " -H "x-api-key: $Hudu__ApiKey" | head -20

Often for cybersecurity compliance frameworks organizations are required to produce an asset list. Hudu is the best way to do this if you are truly documenting all of your assets there. The problem is there are many internal/private fields we would not want to show up on an export that we would produce for compliance. Honestly, if we were to export the data for a client who is leaving we wouldn't want all the data we store there to be exposed so it puts us in a situation to either include LESS data in Hudu, or not give an export. Neither are great options. Ideally there should be a way to set a field to whether or not it displays in a PDF export or not (a simple 1/0 switch would be fine here). This way you can produce annual, quarterly, monthly asset lists for clients right out of Hudu without exposing your internal special sauce or data.

API keys currently only offer a single "view passwords" permission, which also grants access to OTPs. There's no way to grant access to one without the other. Request Split this into two separate permissions on API keys: View passwords – grants access to stored passwords only View OTPs – grants access to OTP codes only This lets admins scope API keys more tightly, for example, issuing a key that can pull passwords for an integration without also exposing OTPS.

As part of our compliance review, a question came up about account lockout. Why isn't this feature part of a Hudu Cloud instance. Rogue users trying to login, IPs as a min should be blocked with the ability to be blacklisted. Yes we can lockdown IP but this should be expanded upon. Also when creating portal members, 2FA should be mandatory when setting up as sometimes this can be missed.

It would be nice if we could create an asset entry in Hudu and then instead of sharing a password with the client, send them a password request. For example, if we are managing the company internet service on behalf of the company and need credentials to access that, we could send a request to the client and they could securely enter it into the form which would update the "Internet Service" asset credentials. This would prevent the credentials from being shared over non-encrypted email or over the phone. I would like this to be a different option than sharing passwords normally, because I don't want shared passwords to be able to be edited by the client unless enabled. It would be bad if they could change passwords that are shared with them without permission. Versioning for this would be important.

Right now, the asset_passwords endpoint returns OTP secrets bundled together with password data. Any integration that needs password data — like a password rotation/PAM platform (e.g., CyberQP) — ends up pulling OTP secrets too, even though it has no legitimate use for them. Ask: Remove OTP secrets from the standard asset_passwords response, and expose them only through a separate field or endpoint that requires its own distinct API permission/scope. Why this matters: This lets us scope third-party integrations to exactly the data they need. A password rotation platform needs passwords, not OTP secrets — bundling the two together means every integration we authorize inherits access to OTP data by default, regardless of whether it needs it. Separating them follows basic least-privilege/need-to-know practice and shrinks the blast radius if any single integration is ever compromised. Bonus: Be able to scope a key to only allow specific clients. Right now, you can do that, but that "client" field is limited to only a specific client.

Add OpenID Connect (OIDC) support for Microsoft Entra ID (formerly Azure AD) and other compatible identity providers such as Okta and Google Workspace.