Process
What a cybersecurity expertise is and how to prepare for it
What the official cybersecurity expertise checks, what the report looks like, and how to prepare your product for it calmly.
· 6 min read

Before launching a website, portal or mobile app, many organizations need to pass the official cybersecurity expertise. It is carried out by specialists of the Cybersecurity Center. The goal is simple: to make sure the product does not leave user data and the organization's infrastructure exposed to known threats.
In this article we draw on our own experience to explain how the expertise works, what it usually focuses on, and how to get your product ready for it.
What the expertise checks
The expertise is an independent assessment of the product as it currently stands. Specialists look at the system the way an external attacker would and record every vulnerability they find in a report.
For web applications
For websites and portals, the review usually covers:
- Application-level vulnerabilities — issues from the OWASP Top 10 (2021) categories: access control flaws, injection, insecure configuration.
- Business logic — whether processes run in the right order and with the required checks.
- Information disclosure — excess internal data in responses, error messages or files sent to the browser.
- Server and network — ports open to the internet, unnecessary services, access to admin panels.
- Transport security — HTTPS, TLS settings and security headers.
For mobile applications
For Android (APK) and iOS (IPA) apps, the review is close to OWASP MASVS and the Mobile Top 10 (2024): binary protection (root/jailbreak detection, protection against dynamic analysis, integrity checks), secure storage of data on the device, correct certificate validation, and network traffic. MD5, SHA1 and SHA256 checksums of the submitted files are also requested, to confirm that the file tested is exactly the one you submitted.
What the report looks like
The result of the expertise is a list of findings. Each one usually comes with a severity level (high, medium, low), a description and a recommendation. The product owner closes the findings and resubmits the product for a repeat check.
For our own product — a tax and finance SaaS platform — the web expertise returned 6 findings: a "payment successful" page shown before the payment provider confirmed the payment, host header injection, two cases of information disclosure, actions possible without state checks, and ports open to the internet. The mobile expertise produced 9 findings across Android and iOS. All were closed, but every round took time.
On resubmission, it may not be just the fixed spot that gets reviewed but the whole product. So when closing one finding, it matters not to introduce a new problem: for example, adding security headers shouldn't break part of the site, and a new library shouldn't bring in an old vulnerability.
The expertise is not an exam but an independent mirror. The better prepared you are, the fewer resubmission rounds you go through.
Preparation: a practical checklist
The following steps are useful for any web or mobile product.
1. Take inventory
Write down exactly what is in scope: domains and subdomains, IP addresses, API endpoints, admin panel URLs, framework and library versions. Problems often show up on a "forgotten" test subdomain or an old API version.
2. Close what you don't need
- Unused ports and services (FTP, database port, server control panel) should be closed to the internet.
- Admin panels should only be reachable from allowlisted IP addresses.
- Test and debug pages,
phpinfo, and old backup files should be removed from the server.
A quick external check of the server:
nmap -Pn -p- your-domain.uz
Only the ports you need (usually 80 and 443) should remain.
3. Check production mode
Debug mode is off, and error messages do not show users a stack trace. The JavaScript sent to the browser contains no list of internal routes, keys or unnecessary configuration.
4. Update dependencies
Use composer audit, npm audit or similar tools to find and update libraries with known vulnerabilities. Server software (nginx, PHP, the database) should be up to date as well.
5. Configure HTTPS and headers
HTTP requests redirect to HTTPS, outdated TLS versions are disabled, and headers such as Strict-Transport-Security, Content-Security-Policy and X-Content-Type-Options are in place.
6. Review business logic by hand
Automated scanners will not find this. In payment, sign-up, password reset and order status flows, make sure every step is validated on the server. For example, payment status should rely on the provider's confirmation request, not on the URL the user was redirected back to.
7. Mobile-specific steps
Build the release with obfuscation, add root/jailbreak detection and certificate pinning, keep secrets in Keystore/Keychain, and disable cleartext traffic. Compute checksums for the APK and IPA in advance:
sha256sum app-release.apk
8. An owner and a paper trail
Assign one technical owner to communicate with the expertise team. Keep a short note for every fix: what was found, what changed, how it was verified. It saves a lot of time at resubmission.
Summary
The expertise independently checks your product's security level, and that is a useful process. Preparing for it means finding and closing the holes yourself before someone else does. The check then finishes in fewer rounds, and the team gets back to its main work sooner.
Want to know how ready your product is for the expertise? Request a security scan — the Claude AI agent and our specialist will review the main vulnerabilities and tell you where to start.


