Aiyoda FAQ

The Aiyoda Console can be securely downloaded from the Aiyoda portal once you have authenticated with a valid username and password. All scanned data is stored in a SQL Server instance hosted within your own environment . This significantly minimises security risks by ensuring your data remains on-premises at all times.

Aiyoda is designed to inventory multiple devices remotely from a single host. You can run additional copies from different devices on separate networks. This is actually recommended for large environments spanning multiple network segments. However, you cannot run multiple instances simultaneously from the same device.

Aiyoda operates across two tiers. The physical tier is entirely managed by you as the customer on-premises. Aiyoda does not host any infrastructure on your behalf. The virtual/logical tier consists of two layers: first, data processing and storage using custom C# code and MS SQL Server; second, reporting which is internal-facing using custom code and Power BI. Everything runs within your own environment.

In most cases no. There is no need to open special ports or change firewall settings. Aiyoda uses standard Windows communication protocols that are typically already open in a domain environment. If an endpoint cannot communicate back to the console device, the scan can also be run manually using Aiyoda Mini and the output imported into the console. The ports used are all customer-configurable.

Aiyoda has a very lightweight network footprint. A successful scan output is on average approximately 20 KB per device , roughly the size of a blank Microsoft Word document. This makes it safe to run across low-bandwidth or congested network segments without any meaningful impact on network performance, even when scanning thousands of devices.

Aiyoda is a complete inventory system where all data is stored directly in SQL Server and reporting is done through Power BI. There is no human interaction with the source data , no manual mapping, no assumptions, no estimates, and no extrapolations. What you see in the Aiyoda dashboard is exactly what you would see if you logged directly into each machine yourself. Aiyoda automatically integrates data from Active Directory, Windows, vCenter, Hyper-V, SQL Server, and Microsoft 365.

Aiyoda collects device and software inventory data , hardware specifications, installed applications, operating system details, and configuration information from Windows, Linux, MacOS, VMware, SQL Server, Hyper-V, and Microsoft 365 environments. Aiyoda does not collect payment-related data and no information is collected directly from individuals. All data is collected by the Aiyoda console and stored within your local SQL Server instance for review.

No. Worms and crawlers do not require authentication, they move freely and are designed to cause damage. Aiyoda requires credentials provided by you, and those credentials strictly limit where Aiyoda can go. Aiyoda only asks questions it has been given permission to ask and returns the required inventory answers in real time. It does not write to target devices, does not modify any configuration, and cannot be used as an attack vector.

There is no need for expensive on-premises infrastructure. You need at least one Windows Workstation or Server (physical or virtual) with Microsoft .NET Core, SQL Server, and Power BI Desktop installed. This machine requires internet access to download files and to extract data from Microsoft 365 Graph API. All other scanning is done within your local network using the credentials you provide.

A risk assessment has been completed for the current version and appropriate measures are in place. The application uses parameterized (prepared) SQL statements to eliminate the risk of SQL injection. External parties cannot see the Aiyoda data structure and there is no ability to query SQL directly from outside the environment. The data schema is fully internal and not exposed via any public API.

Aiyoda is implemented in C#, leveraging the .NET framework for its core functionality including device scanning and data processing. This is a well-established, enterprise-grade technology stack with strong tooling support for security practices, dependency management, and long-term support from Microsoft.

No, developers do not have access to production. When a new version is ready it is first pushed into a testing environment. Once the testing manager approves and signs off, the deployment is pushed into production. Testing is done using test data only. If production data is ever required for testing, it is sanitised to prevent disclosure of confidential data to unauthorised staff. Developers do not have operational responsibility or the ability to access operational data.

All code changes go through a peer-review process. Once accepted they are pushed into testing where the testing manager must approve and sign off before production deployment. Emergency changes are performed manually and typically take less than 48 hours. Change control procedures, including back-out procedures and escalation paths, are fully documented.

No, everything is developed and maintained in-house. There are no third-party development, administration, or hosting relationships that affect the Aiyoda product or service. All development, testing, and deployment is handled internally by the Aiyoda team.

Aiyoda Technologies maintains a comprehensive IT security policy that is reviewed with all staff. All policies, standards, and procedures are reviewed on an bi-annual basis. Risk assessments are conducted to identify threats and vulnerabilities, coupled with periodic assessments to ensure organisational compliance with policies and standards.

All employee and contractor agreements include confidentiality clauses, reference security responsibilities, and identify penalties for non-compliance. Staff have minimum necessary access to confidential data based on their role and need-to-know. When a staff member is terminated, there is a formal process in place to remove access to buildings, systems, and all other resources within 24 hours of termination.

Administrative access uses extended authentication with multi-factor authentication (MFA). All access to any database containing confidential information is authenticated. There are no clear-text logins to any internet-accessible systems. This ensures that even if credentials are intercepted, they cannot be used without the second authentication factor.

A formal Incident Response Plan is in place to notify management of any significant alerts, security breaches, or incidents. The plan is tested annually. Escalation and response procedures cover prolonged service disruptions including natural disasters and power failures. Contingency and business recovery plans are formally documented, tested, and reviewed annually and are assigned to a designated responsible officer. Segregation of duties ensures security administration is performed by dedicated staff separate from operational support staff.