GuardPoint10 Cybersecurity Assessment
Customer and Partner Briefing
GuardPoint10 (GP10) is the system that decides who enters which door, when, and on whose authority.
Sensor Access holds GuardPoint10 to the security standard expected of professional access control deployments. To meet this standard, we commissioned a comprehensive in-house security assessment, including a full penetration test of the product.
The purpose of the assessment was to identify and address realistic attack paths before they could be exploited and to give customers a clear, documented route towards a production-grade deployment.
Assessment at a Glance
| Assessment measure | Result |
|---|---|
| Security domains assessed | 8 domains assessed end to end |
| Critical-severity findings | 100% of identified critical issues resolved in code |
| Remediation approach | Two-track remediation model |
| Software supply-chain record | Software Bill of Materials generated during penetration testing |
The Bottom Line
All critical-severity issues identified during the assessment have been resolved in code, closing the realistic “first-day” attack paths found during testing.
The assessment has been designed to be reproducible and is re-run against new GuardPoint10 releases. An independent external penetration test is also planned to validate the results.
Key Principles of the Assessment
| Principle | What this means |
|---|---|
| Real-world evidence | Findings were reproduced on a clean machine that mirrored a fresh customer installation. Testing focused on what proved exploitable rather than what was only theoretically possible. |
| Defence in depth | Coverage included the source code, running server and API, operator client, Windows services, SQL database, network encryption and version history. |
| Fixed at the source | Critical fixes are incorporated into the GuardPoint10 installer, allowing customers to benefit when upgrading without having to apply separate fixes. |
| Documented hardening | Customer-configurable measures are recorded in a companion GuardPoint10 Hardening Guide with step-by-step instructions and a plain-English explanation. |
Assessment Scope
The assessment examined GuardPoint10 end to end, from the application source code through to a fully running system installed in the same way it would be supplied to a customer.
Eight areas were examined for realistic, exploitable weaknesses.
| No. | Assessment area | What was examined |
|---|---|---|
| 1 | Application source code | Reviewed for insecure coding patterns, including weak authentication, unsafe data handling and hard-coded secrets. |
| 2 | Server and third-party API | Tested with malformed and unauthorised requests to confirm that access was properly enforced by the running services. |
| 3 | Operator desktop client | Examined to determine how login credentials are protected and how the client verifies that it is communicating with the genuine server. |
| 4 | Windows services and permissions | Reviewed to identify the privileges assigned to each service and who can modify GuardPoint10 files and configuration. |
| 5 | SQL Server database | Assessed for access control, auditing, encryption and the protection of stored personal data. |
| 6 | Network and encryption – TLS | Tested to confirm that modern encryption protocols are used and that connected components verify each other’s identity. |
| 7 | Third-party libraries | Inventoried and checked against public vulnerability databases for known and published weaknesses. |
| 8 | Version-control history | Scanned for credentials or other sensitive information that may previously have been committed to the code history. |
Reproduced, Not Theorised
Findings were reproduced on a clean test machine that mirrored a fresh customer installation before they were formally recorded.
Theory-only findings were set aside. The assessment focused on weaknesses that proved exploitable during testing rather than risks that were merely possible on paper.
This kept the assessment grounded in realistic risks and allowed remediation work to remain focused.
Tools and Methodology
The assessment used industry-standard, freely available tools across several security disciplines. These were selected so that the results would be transparent, repeatable and independently verifiable.
| Assessment area | Tools used | What the testing checked |
|---|---|---|
| Source-code analysis | Semgrep and DevSkim | Insecure coding patterns, weak authentication, unsafe data handling and hard-coded secrets. |
| Dependency and supply-chain analysis | OSV-Scanner, Trivy and CycloneDX | Known vulnerabilities in third-party libraries and the creation of a Software Bill of Materials. |
| Live API testing | Custom probes and schema fuzzing | Authentication-bypass attempts and malformed input sent to the running services. |
| Desktop-client analysis | ilspycmd and automated UI driver | How the client handles credentials and verifies the identity of the server it connects to. |
| Service and system audit | AccessChk and Windows tooling | Service privileges, file-system permissions and scheduled tasks. |
| Database testing | T-SQL probe scripts | Login policy, auditing gaps, encryption and the protection of data at rest. |
| Encryption testing | sslyze and OpenSSL | Protocol versions, encryption ciphers and certificate validity against modern standards. |
| Secret scanning | gitleaks and trufflehog | Credentials accidentally committed to the source-code history. |
| Live reproduction | Isolated test virtual machine and automation | End-to-end confirmation using a clean, fresh-install environment. |
Methodology Summary
| Methodology principle | Description |
|---|---|
| Transparent | Open and widely used tools allow findings to be reproduced and audited by a competent third party. |
| Repeatable | The toolchain is automated and re-run against new GuardPoint10 releases. |
| Comprehensive | The source code, running application, Windows host, database and network are covered. No single layer is trusted blindly. |
Closing the Gaps
A clear two-track rule was applied to every finding.
| Remediation track | How it is handled | Customer action |
|---|---|---|
| Track A: Fixed in code | The correction is incorporated into GuardPoint10 and supplied through the installer. | Customers benefit when upgrading. No separate action is normally required. |
| Track B: Hardening Guide | The measure depends on the customer’s infrastructure, policies or operational requirements. | The customer or their IT provider follows the companion GuardPoint10 Hardening Guide. |
Track A: Fixed in Code
The following improvements are incorporated into GuardPoint10 and supplied automatically through the installer.
| Improvement | Security benefit |
|---|---|
| Reduced service privileges | Each GuardPoint10 service runs under its own minimal-permission identity rather than a high-privilege account. |
| File-permission hardening | The GuardPoint10 working directory is no longer writable by ordinary local users, reducing the risk of configuration tampering. |
| Stronger authentication | Login tokens are verified, sensitive endpoints require authentication and invalid tokens are rejected. |
| Verified identity and encryption | GuardPoint10 components verify each other’s certificates over modern TLS, reducing the opportunity for local-network interception. |
| Patched dependencies | Third-party libraries with known critical or high-severity vulnerabilities were upgraded. |
| Hardened defaults | Web endpoints use modern security headers, SQL login auditing and password policies are enabled during installation, and application files are code-signed. |
What This Means for Customers
Critical product-level corrections are supplied as part of GuardPoint10 itself. Customers therefore receive these improvements when upgrading, rather than having to identify and apply each correction manually.
Track B: GuardPoint10 Hardening Guide
Some security controls depend on decisions that only the customer or their IT department can make for their environment.
These measures are documented in the companion GuardPoint10 Hardening Guide with clear instructions and a plain-English explanation.
| No. | Hardening area | Guidance provided |
|---|---|---|
| 1 | SQL account model | How database logins should be structured according to the principle of least privilege. |
| 2 | Data-at-rest encryption | Options such as SQL Server Transparent Data Encryption or Windows BitLocker for protecting stored data. |
| 3 | Application allowlisting | The use of Microsoft AppLocker or Windows Defender Application Control to control which application files may run. |
| 4 | Backup and recovery model | Guidance for creating a resilient backup strategy suited to the individual deployment. |
| 5 | Optional network-layer encryption | The use of IPsec in environments that require encryption below the application layer. |
Where This Leaves GuardPoint10
The assessment moves GuardPoint10 from secure installer defaults towards a clearly documented, production-grade deployment model.
| Current position | Outcome |
|---|---|
| Critical paths closed | All critical-severity findings identified during the assessment were resolved directly in the product code. |
| Continuously verified | The security toolchain is re-run against new GuardPoint10 releases. |
| Guided hardening | The companion Hardening Guide helps customers take an installation towards production-grade configuration. |
| Security improvements supplied by default | Customers receive product-level corrections automatically when upgrading. |
| External validation planned | An independent external penetration test is planned to confirm the results. |
| Self-service hardening | Customers and their IT teams can follow the Hardening Guide using clear, plain-English instructions. |
Assessment Conclusion
All critical-severity issues identified during the assessment have been resolved in code, closing the realistic “first-day” attack paths found during testing.
Remaining items are either scheduled for an upcoming release or documented as customer-configurable hardening measures.
| Assurance measure | Position |
|---|---|
| Critical-severity findings | Resolved directly within the GuardPoint10 code |
| Remaining configuration measures | Documented within the Hardening Guide |
| Software Bill of Materials | Generated during penetration testing |
| Repeat testing | Assessment is re-run against new releases |
| Independent testing | External penetration testing is planned |
Responsible Disclosure
This summary intentionally avoids publishing specific details about individual findings, in accordance with Sensor Access Technology’s responsible-disclosure policy.
Detailed technical findings are retained within internal documentation and may be shared with customers under that policy upon request.
This document reflects the findings as understood at the time of testing and is provided for information only. It is not a warranty, guarantee or assurance of security.
The security of a GuardPoint10 installation also depends on its correct deployment, configuration and maintenance by the customer and their appointed installers or IT providers.
Questions About GuardPoint10 Security?
| Contact method | Details |
|---|---|
| Telephone | +44 (0)1273 242 355 |
| sales@sensoraccesscontrol.com | |
| Website | www.sensoraccesscontrol.com |
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article