nvaccess
Corporate mode for NVDA
Is your feature request related to a problem? Please describe.
Corporate (security) mode for NVDA. This mode is intended to enhance security while allowing certain configuration settings to be saved, providing a balance between security and customisability for enterprise environments.
Describe the solution you'd like
The solution involves developing a new mode called "Corporate Mode" which is based on the current "Secure Mode". The development plan includes the following features for version 1.0:
- Save configuration for most settings.
- Allow changing and saving of settings related to speech, braille, audio and vision preferences, keyboard preferences and mouse settings, review cursor, input composition and object presentation.
- Essentially exclude advanced settings and any settings that require administrative privileges to modify.
- Save gesture map / custom keyboard shortcuts and gestures for NVDA functions.
- Allow users to create, save and switch between different configuration profiles.
- Provide access to user documentation from within NVDA without requiring elevated privileges.
- Disable any features that require admin or elevated access.
- Addons are enabled, but disable installation of new addons.
- Disable the Python console.
- Disable custom configuration loading (-c).
- Disable creating portable installations.
- Rebrand existing "Secure Mode" to "Kiosk Mode".
- Creation of documentation for Corporate Mode (eg: setup guide, usage scenarios, enterprise troubleshooting tips). This is essentially Secure Mode with a few punch-outs.
Describe alternatives you've considered
We could soften the existing "Secure Mode" by adding the required features directly into it. However, creating a distinct "Corporate Mode" allows for clearer differentiation and there is still a need for a fully locked-down mode. To avoid confusion with NVDA's elevated security during sign-on screens, the existing Secure Mode will be renamed Kiosk Mode.
Additional context
Features that are likely not to be included in version 1.0 but can be considered for future updates based on user feedback include:
- Checking for updates & auto-updates.
- Updating addons.
- Configurability of policy whitelist/blacklist.
- Allowing admins to enable/disable the log viewer.
- Allowing users to install/update specific addons from a whitelist.
- Integration with Active Directory / Group Policy
- Admin dashboards
Please note: The original issue created for this became a very useful discussion on the current state of UIA implementation, and was moved to a discussion so as to separate it from this corporate mode proposal, but not to lose it.
The original issue created by @gerald-hartig has been moved to discussion #16600 The discussion around the current state of UIA implementation was very useful and is worth continuing there. To address the potential need to change UIA settings for the current application when in corporate mode, I have proposed issue #16598 for a gesture to change UIA settings on the fly (which would also likely help corporate users who need to change from the default UIA setting for a specific situation but return to it in other cases).
Please include the possibility of installing new organization-approved addons, there are very good addons that enhance the productivity for some users but other users might find they are not necessary for them.
Please include the possibility of installing new organization-approved addons, there are very good addons that enhance the productivity for some users but other users might find they are not necessary for them.
This would be possible - this is also possible currently in secure mode. How it would work currently is that the admin would setup NVDA however they need - including whatever add-ons are required - then set NVDA to use secure mode (eg using the "forceSecureMode" registry key). (if you needed to make changes later, you could disable the registry key, make the changes, then re-enable the key). So this kind of approach would also work with corporate mode.
This can work if the user has permission to change the registry, however in some scenarios the user only has permission to work in a non-privileged account, in this case only the system administrator has the admin privileges of the computer, in this case the user would be unable to install addons without the administrator doing the procedure of disabling the registry key, installing the addon and re-enabling it. A list of approved addons that the user could install would make it easier for the user to have freedon of installing the addons based on the approved list and the system administrator that would not need to individually install addons for every user.
Could the process for managing addons receive extra attention, particularly when operating in a corporate environment? I foresee potential bottlenecks including delays, follow-up requests, and numerous ticket submissions to have a single addon approved or whitelisted. It would greatly benefit IT teams to have clear guidance on addon review procedures, including instructions or direct links to examine source code. Much of this information is already available in NVDA's addon store. While advanced NVDA users may navigate these processes with ease, everyday users may struggle. In a corporate mode Addons store, a dedicated tab could be maintained listing all available addons, alongside a button to streamline the data submission process for cyber review. This way, users could easily locate the desired addon, click the button, get the needed info in their clipboard, proceed to pasting it in an Email or ticket form and submit all necessary information to reviewers. May be there's a better way to do this, above was just 1 way that came to mind.
@thgcode @RuturajL With the add-ons, we want to get the basic functionality for persisting settings out as quickly as possible, as the feedback we've received is that this will have a large impact to a large number of users. Settings persistence is therefore a must-have. With the add-ons (Allowing users to install/update specific addons from a whitelist) we prioritised this as a priority for a later version since there will be are workarounds (having the admin install add-ons individually rather than the user).
For the v1.0 release we want to deliver the minimum set of features that must be there in order for Corporate Mode to be useful to the users. If we add more features into v1.0, this will delay the release of v1.0, which is fine if the features are must-have features. At the moment the feedback we're seeing is that more advanced add-on handling is very nice to have, and once we have feedback from users on how v1.0 is performing in the wild, we can prioritise it for the next release.
Of course if you feel that Corporate Mode has no value to users without the add-on functionality, and is a must-have feature, I invite you to make that argument.
@gerald-hartig, fully agree on doing the most important things for v1. This would promote use of NVDA in corporate environments hopefully. Obviously this would go through beta testing etc, so I am hoping all the issues would be ironed out before corporates start implementing it left and right. I do feel addons are critical in work environments. However, even under current process, users would be probably requesting for admin access or IT helpdesk's assistance for installing addons in such corporate environments, so, hopefully this wouldn't be a big change for them.
Hi, small feedback from corporate security in a large company : our EDR just started alerting on nvdaHelperRemote.dll on vague grounds related to malware similarity and being loaded in sensitive ( browser ) processes. I just went through the several issues related to Remote Access & Corporate Mode, and couldn't find a registry setting I could remotely use to force-disable anything remote. I notably saw the #18018 issue about autoupdates. Ideally , another setting that would enable us ( corporate security ) to automatically block anything remote would be great. If that could be the default on domain-joined windows ( usually equivalent to enterprise mode ) that would be even better, since no security team would have to invest work in coercing NVDA to follow $enterprise security policies. ( Which usually are : no updates ( prevents supply chain compromises attacks ) no remote access ( obvious takeover risk ) )
In my case, I just uncovered ~100 users of NVDA and can't afford chasing where the config files are on their laptops, nor do tech support for every one of these users to ensure they disable the remote access feature.
Also, some hints on where the documentation is for such registry keys would be welcome ( these issues are well organised & linked together, that's good enough, but I coudl not find the registry key related to blocking remote access ).
Finally, having a separate DNS domain name for the remote control features & updates would be really helpful for security incident responders. I just checked and my users are accessing :
- nvaccess.org
- www.nvaccess.org
- download.nvaccess.org
- api.nvaccess.org
- download-nvaccess-org.webpkgcache.com
- addonstore.nvaccess.org
I doubt all users accessing api.nvaccess.org are doing so while using the remote control feature. If you could have updates hit download.nvaccess.org/updates.nvaccess.org and remote control hit something like remote-control.nvaccess.org, that would allow us security brutes to detect/block at the network/DNS/firewall level without breaking the rest of what api.nvaccess.org offers.
Thanks for implementing such an important piece of software, and thanks for reading !
Hi,
The NVDA helper remote process is crucial for enabling browse mode support in browsers such as Chrome, Edge, and Firefox where code injection offers an efficient way to retrieve web document content for further processing. Blocking it can have consequences such as inability to use browse mode to access business applications hosted on intranet environments. While newer browser releases improve accessibility API support and thus minimizes the need for code injection, some parts of modern accessibility API implementations, notably Microsoft UI Automation, can pose problems in web browser usage due to incomplete implementations and thus NVDA elects to rely on IAccessible/IAccessible2 support (necessitating code injection based browse mode implementation). Further, we NVDA contributors continue to support older technologies as we understand that it takes time for enterprises to migrate to new software releases, and for older web browsers used in corporate environments, code injection mechanism provided by NVDA helper remote library is needed.
Thanks for understanding.
@59e5aaf4, have you read NV Access Corporate & Government page?
It's also worth adding that nvdaHelperRemote.dll has been in NVDA for ages; it has nothing to do with Remote Access feature introduced in NVDA 2025.1. Other people may probably explain why this dll is named this way...
Oh. You mean nvdaHelperRemote.dll is for remote process injection (process-to-process), not remote computer access (computer-to-computer). That likely is why our EDR got angry then, Nevermind.... :D Thanks for the documentation link, I'll ensure we consider using the secure mode. Sorry for the noise !
I cannot wait for this issue. I need to disable the update check today as it bubbles now with 2025.1.1. Can I delete a file from 2024.2 to break the update process? Block an specific url? What are the files in the project that are fetching the updates or ask the api if a new version is available? I’m willingly to delete involved files only to break the update check. What can be done today to force-stop the update?
@alexhass can you set up what is described in NV Access Corporate & Government page? Is it enough for your needs?
@alexhass can you set up what is described in NV Access Corporate & Government page? Is it enough for your needs?
I have no money for you if you mean this. I just care about a working setup and software and provide my high skilled expierience and feedback for free.
Hi,
Do the following and tell users:
- Open NVDA menu (NVDA+N).
- Go to Preferences -> Settings.
- From General tab, go to "Automatically check for updates to NVDA" and uncheck it.
- Click OK, and NVDA will no longer check for updates.
I wil address folder access issue in the other issue.
Thanks.
@alexhass wrote:
I have no money for you if you mean this. I just care about a working setup and software and provide my high skilled expierience and feedback for free.
Just to clarify — I wasn’t referring to any paid service. I only meant the technical setup for Secure Mode described on that page. Does it fit your needs?
Hi, small feedback from corporate security in a large company : our EDR just started alerting on nvdaHelperRemote.dll on vague grounds related to malware similarity and being loaded in sensitive ( browser ) processes. I just went through the several issues related to Remote Access & Corporate Mode, and couldn't find a registry setting I could remotely use to force-disable anything remote. I notably saw the #18018 issue about autoupdates. Ideally , another setting that would enable us ( corporate security ) to automatically block anything remote would be great. If that could be the default on domain-joined windows ( usually equivalent to enterprise mode ) that would be even better, since no security team would have to invest work in coercing NVDA to follow $enterprise security policies. ( Which usually are : no updates ( prevents supply chain compromises attacks ) no remote access ( obvious takeover risk ) ).
This is a remote injection process for browsers like Chrome, and Firefox, as well as to get at certain types of information like display info for various processes. In-process injected code, so remotely injected code via dll. The reason your EDR flagged this is because your EDR saw the injected code happening in various processes, which is going to look like malware, as most software really doesn't need the privs necessary to inject. Cheers, Derek
Also, may we considder corporate mode being configurable? I.E. some corpos would like to allowlist specific addons, but not make them installable by everyone. Some corpos would like to enable users to have remote support, but on a specific relay, corporate managed remote server relay. I assume the NVDA Remote server is being open sourced.
@alexhass wrote:
I have no money for you if you mean this. I just care about a working setup and software and provide my high skilled expierience and feedback for free.
Just to clarify — I wasn’t referring to any paid service. I only meant the technical setup for Secure Mode described on that page. Does it fit your needs?
I tried SecureMode with latest 2025.1.1 deployment and it seems working for now. At least the update checkbox that admin only can change is gone… totally invisible/hidden, not only greyed out. Has this screen reader reasons? 😉
Hi,
Do the following and tell users:
- Open NVDA menu (NVDA+N).
- Go to Preferences -> Settings.
- From General tab, go to "Automatically check for updates to NVDA" and uncheck it.
- Click OK, and NVDA will no longer check for updates.
I wil address folder access issue in the other issue.
Thanks.
Only admins can do this… so no user can change it.
Added the ForceSecureMode via PSADT into HKLM in the latest deployment.
