Last updated March 9th, 2023
Keygen LLC ("Keygen") operates several websites and services including keygen.sh and related subdomains. It is Keygen's policy to respect your privacy regarding any information we may collect while operating our services.
1. The GDPR and Keygen
1.1. On privacy, the GDPR and why it is important
To offer greater privacy and control of data for individuals who use or are stored within our services, we will apply the GDPR to all individuals who are stored within or use our services, whether inside or outside of the EU.
We believe in the GDPR and in increased privacy for everyone.
1.2. General Data Protection Regulation (GDPR)
In 2016, the European Commission approved and adopted the new General Data Protection Regulation (GDPR). GDPR is a significant change in data protection regulation in the EU and replaces the existing legal framework (the Data Protection Directive and the various member state laws).
The GDPR is a comprehensive set of regulations that dictates what companies like Keygen must do in order to properly protect our customers' data. Even though we are not a European company, we have many customers in the EU and we fully comply with these regulations. This document explains in simple terms what we're doing in order to ensure compliance.
It will come into effect on May 25, 2018.
Note: The full GDPR regulations are extremely long and complicated. This isn't meant to be a comprehensive list of every single thing we do to protect your data, but rather it's a simple summary so that you can have a good idea of the protections we have in place. Please feel free to reach out to us if you have questions about specific items that aren't addressed here.
1.3. How GDPR applies to Keygen
GDPR defines three parties, which we will reference throughout this document:
- Data Subject - This is the person about whom data is being stored and used. Any user that you store within our systems (i.e. your customer) is a data subject. You are also a data subject, because you have an account with Keygen (i.e. you're our customer).
- Data Controller - This is the person or company that is using the data that's being stored. You (our customer, and a user of Keygen) are a data controller. We are also a data controller, concerning your personal data, because you have an account with Keygen.
- Data Processor - These are companies that create tools to actually store and take advantage of the data. We (Keygen) are a data processor.
The data Controller and Processor both have different responsibilities to ensure that we are acting legally and ethically. This document explains what we do to comply with GDPR as a Processor, and how we use the data we collect, but you should keep in mind that you also have responsibilities to the people who's information you store using Keygen
1.4. Technical security
As a company focused on software licensing, our customers entrust us with very important data for their businesses. Keeping your data secure and private is of the utmost importance, and so we are careful to follow industry best practices. A lot goes into online security, but here are some of the main things we do that might interest you:
- Our servers are hosted by Heroku as well as directly by Amazon Web Services (AWS). Heroku also uses AWS for their infrastructure, so all of our servers are hosted on AWS, some managed by Heroku, some not. AWS is the largest and (in our opinion) most sophisticated hosting company in the world, and they have extensive physical and digital security in place.
- We use 256-bit encryption at all levels of our software. All connections to our website are encrypted (i.e. we encrypt "in transit"), our live database is encrypted (i.e. we encrypt "at rest") and all of our data backups are encrypted.
- We never store passwords as plain text – they are always hashed and salted securely using
bcrypt. We also do the same with all API access tokens.
- Our main servers are in Virginia, USA at Amazon's US-East data center. We also keep encrypted backups of data in other locations within the USA in case anything happens to the Virginia data center.
- All Keygen employees are required to use non-SMS 2FA on all first- and third-party services. When non-SMS 2FA is unavailable, we require use of SMS 2FA. We always require strong passwords, regardless of 2FA availablility.
- We regularly perform external vulnerability scans and application penetration tests to monitor the status of our security efforts.
If you have questions or concerns, reach out to us at [email protected].
1.5. Data Transfer
Keygen complies with certain legal frameworks relating to the transfer of data from the European Economic Area, the United Kingdom, and Switzerland (collectively, EU) to the United States. When Keygen engages in such transfers, Keygen relies on Standard Contractual Clauses as the legal mechanism to help ensure your rights and protections travel with your personal information. To learn more about the European Commission's decisions on international data transfer, see this article on the European Commission website.
1.5.2. Standard Contractual Clauses
Keygen relies on the European Commission-approved Standard Contractual Clauses (SCCs) as a legal mechanism for data transfers from the EU. SCCs are contractual commitments between companies transferring personal data, binding them to protect the privacy and security of such data. Keygen adopted SCCs so that the necessary data flows can be protected when transferred outside the EU to countries which have not been deemed by the European Commission to adequately protect personal data, including protecting data transfers to the United States.
The SCCs are a pre-approved data transfer mechanism under GDPR, applicable in all EU Member States, which enable the lawful transfer of personal data to countries outside of the European Economic Area that have not received an adequacy decision from the European Commission (third countries).
To learn more about the SCCs, see this article on the European Commission website.
To obtain the SCCs, please reach out to [email protected], or visit the page listed above.
1.6. Data Processing Addendum
GDPR requires that we have a contract, called a Data Processing Addendum (DPA), with our customers which specifies things like how we process data, that we will assist you in your GDPR obligations to your customers, etc. In our case, our Data Processing Addendum is our standard Terms of Service, which applies to all of our customers, including you.
To obtain a copy of our Data Processing Addendum, please reach out to [email protected], or visit the page listed above.
1.6.1. Changes to our DPA; other DPAs
To ensure no inconsistent or additional terms are imposed on us beyond that reflected in our standard DPA and model clauses, we cannot agree to sign customers' DPAs. As a small team we also can't make individual changes to our DPA since we don't have a legal team on staff. Any changes to the standard DPA would require legal counsel and a lot of back and forth discussion that would be cost prohibitive for our team.
1.7. Data Processing Officer
We have appointed a Data Protection Officer. They may be contacted at [email protected].
1.8. Data Breach Notification Plan
We work hard to keep our software secure so that there are no data breaches, but in the event that there is a data breach, we have a plan in place that fully complies with the requirements laid out by GDPR. You can read our full plan below, but the basic idea is that if we become aware of a data breach, we will notify any of our customers who may have been impacted, and provide them with the appropriate information so that they can also comply with their responsibilities as a Data Controller.
The specifics of our response to a data breach would of course depend on the details of the breach itself (the method of the breach, what data was compromised, etc.) but here is an outline of how we will approach the situation:
1.8.1. Identifying a breach
The first step in responding to a data breach is knowing that one has happened in the first place. We monitor the status of our security with technology (running penetration tests and network scans) as well as policy (training employees on what to look out for, making sure issues are escalated appropriately).
If we ever identify a breach, or even notice something out of the ordinary that justifies investigation, we will take the following steps:
1.8.2. Assigning roles and responsibility
At any company, the best way to ensure that an issue is taken seriously is to make sure that it has the attention of top leadership. Keygen has one individual who will personally handle all security concerns. Ezekiel ("Zeke") Gabrielse, the Founder and CEO, will be responsible for organizing the company-wide response, assigning roles, and ensuring that we do everything outlined in this document and more to handle the situation as thoroughly as possible.
Every member of the company knows that if there is ever a security concern, the issue should go directly to the CEO without any delay.
1.8.3. Investigate the type and scope of the breach
Breaches can happen in many different ways. They can be the result of a technical or social failing on our end. In many cases, the customer may have been tricked into giving their login information to the attacker, and it might not be the result of insecurity in the software at all.
In order to decide how to respond to a breach, we must first understand how the breach happened. We will seek to answer the following questions as quickly as possible:
- Was there some sort of failure of our technology or processes that enabled the breach?
- What data was accessed?
- What was (or might have been) done with the data? I.e. deleting data is different from exporting it outside our server.
- How many users were impacted?
1.8.4. Address immediate threats
If we find that the breach is caused by a customer's login information being compromised (e.g. two business partners are fighting over ownership of the business and one steals the other's account login information) we will shut down API access for the account in question until we are confident that the rightful owner is the only one with access. In some cases this can take several days or longer as there may be legal issues outside of our control that must be adjudicated first.
If we determine that the breach occurred due to an vulnerability on our end, we will work to fix whatever the vulnerability was as quickly as possible to prevent further damage. If a situation like this ever arises, every employee at Keygen who can be helpful will treat this as their top priority and set aside any other responsibilities until the problem is resolved.
1.8.5. Notify the appropriate parties of the breach
This step will depend heavily on the details of the breach. For example, in a situation where a specific user is phished, they will likely already know about the breach, and it wouldn't impact any of our other customers. But if our entire database is compromised by a hacker, that would potentially impact all of our users (our customers, as well as your customers).
Our general guideline is that if there's a reasonable possibility that the breach will have a negative impact on a customer, we will notify them quickly. "Quickly" can mean different things depending on how long it takes us to conclude our investigation, but when possible, our goal would be to send notifications no more than 72 hours after we become aware of the issue.
1.8.6. Your responsibilities
Note: If you or your customers are in the EU then you may be subject to the GDPR data breach notification rules. This basically means that if you are storing private information about a person in our systems and that data is breached, you may be responsible for notifying that person the same way we are responsible for notifying you (this is true with any service you use, not just us). If this happens, we will work with you to make sure that you have all the information possible so that you can comply with the GDPR.
1.9. Trusted third-party services we use
We may share data with the following third-parties, also known as Subprocessors under GDPR, so that we can offer our services to you, and so that we know how to continue improving our services to remain valuable to you.
- Cloudflare for our DNS, CDN, DDoS mitigation, and reverse proxy
- Stripe for payment processing
- Fathom for privacy-first analytics
- Rewardful for our affiliate program
- Papertrail for log management
- IPInfo for IP geolocation and threat data (e.g. to determine if you're from the EU, using the TOR network, etc.)
- SendGrid for sending transactional email
- Heroku and AWS for hosting our infrastructure
- Algolia for documentation search
- Zapier for workflow automation
- ProfitWell for BI
We have Data Processing Addendums with all of our Subprocessors.
1.10. Information we collect on our customers (i.e. you)
If you have a Keygen account, we are the Controller of your personal information (PI). The data below is stored locally within our systems (unless noted otherwise), and may also be stored in a third-party service listed above. All logs are scrubbed of sensitive info (passwords, tokens, etc.) locally before being sent over the wire.
1.10.1. Personal information and unique identifiers
- Unique user and account IDs
- Unique Stripe customer and subscription IDs
- First name
- Last name
- Hashed password (hashed using
- Company name
- Credit/debit card information (locally, we store the last 4 digits of your payment method, the brand, and the expiry – all other data is stored securely within Stripe)
- IP address for API rate limiting (stored for up to 30 days, but likely purged within 24 hours)
- IP address via API request logs (we have a 30 day log retention)
- Date/time of resources being accessed via API request logs (again, 30 day retention)
1.11. Information we store on your customers
We are the Processor of your customers' data (the licensed users of your software products), you are the Controller of said data. We never share your customers' data with any third-parties outside of our log management services and other infrastructure-related services. The data you store within Keygen is owned entirely by you.
1.11.1. Personal information and unique identifiers
- Unique user ID*
- First name*
- Last name*
- Hashed password* (hashed using
- IP address for API rate limiting (stored for up to 30 days, but likely purged within 24 hours)
- IP address via API request logs (we have a 30 day log retention)
- Date/time of resources being accessed via API request logs
- The following information on machines (devices) associated with a license:**
- Fingerprint of the device (this is an arbitrary string, which could include data such as HDD ID, MAC address, IP address, etc. – we encourage our customers to hash this data using a strong hashing algorithm, e.g. sha256 or sha512, so that it's anonymized)***
- IP address of the device
- Hostname of the device
- Name of the device
- Platform of the device
- Any other PII stored within a resource's
metadataattribute, e.g. tokenized CC information, billing address, Stripe customer ID, PayPal transaction ID, etc. (keep in mind that you as a Controller are responsible for this data)
* These attributes are for our
Userresources, which is an optional feature. You do not have to utilize this feature if it is not required for licensing your products.
** These attributes are for our
Machineresources, which is an optional feature.
fingerprintattribute is for our
Machineresources, and can be anonymized to not store any PII by hashing the data using a cryptographically secure hashing algorithm.
1.12. Data retention
All of the above data for both our customers and your customers could be included within our logs (e.g. within database query logs, request logs, etc.), backups, and within temporary storage (e.g. caching systems, our Redis datastores, etc.), which we keep for up to 30 days.
Before the maximum 30 day retention period, all archived logs, backups, and temporary storage are permanently deleted – this means that after a user has been "forgotten" i.e. erased upon request, the user will be completely erased from our systems within 30 days.
1.12.1. Webhook resource snapshots
All of the above data for both our customers and your customers could be included within a webhook event resource snapshot. Resource snapshots are taken at the time of the event, e.g. a
user.created webhook event will include a
payload attribute with a JSON snapshot of the user resource, which may include PII for that user. Webhook data is retained for up to 90 days.
You can delete webhook events through the API or your Dashboard.
1.13. Data subject rights
Our customers and your customers, the Data Subjects, are entitled through their Data Subject Rights (DSR) to access ("Right To Access"), export ("Right to Data Portability"), change, and permanently delete ("Right To Be Forgotten") all their data from our systems.
If we receive a request from one of your customers (a Data Subject) to access, change, export, or delete their data stored within our systems, we, the Processor, will forward the request to you, the Controller, without delay. You have the ability, via our APIs and your Dashboard, to handle said data as requested by the Data Subject.
We, the Processor, will not change, export, or delete data on or for any of your customers, a Data Subject, unless it is required by law or by our Terms of Service, or unless we have received documented instruction from you, the Controller, to do so.
DSR requests can include personal data of other individuals, like your employees or customers that you have provided to us and who have requested this of you. We will respond to these requests within 14 days or less, which is well within the GDPR requirement of 30 days.
DSR requests may be sent to [email protected].
1.14. Lawful basis for processing
GDPR requires that we establish that our data processing is legally justified. They give a variety of reasons it might be valid, and the following is the one that applies to us:
...processing is necessary for the purposes of the legitimate interests pursued by the controller…
Our interpretation of this is that you, as the Controller, have legitimate business interests in using our services to license, distribute and sell your products, and we're assisting you in pursuing those interests. Keep in mind that this only applies so long as the Controller (you) respects the individual rights of the Data Subjects.
We only collect data that is necessary for the purposes of making our services valuable to you.
1.15. Your responsibilities
As explained above, we are in the role of Data Processor and you are the Data Controller. If you store your customers' information in our systems, you can be confident that we are handling GDPR compliance on the data processing side of things (and as the Controller of your data), but you are still responsible for being compliant as a Controller of your customers' data. (This would be true regardless of what licensing service you use, so there's no avoiding it.)
If you're concerned that you aren't in compliance, we encourage you to research this topic in more detail, but a good starting point is to ensure that you honor the individual rights laid out in the GDPR regulations to your customers.
1.16. Revisiting GDPR compliance regularly
As part of our commitment to remaining GDPR compliant and respecting the privacy of our users, we will revisit this document at least once per year to ensure that all of the information is accurate and up-to-date. If you have questions or concerns, contact us at [email protected].
2.1. Website visitors
Like most website operators, Keygen collects non-personally-identifying information of the sort that web browsers and servers typically make available, such as the browser type, language preference, referring site, and the date and time of each visitor request.
Our purpose in collecting non-personally identifying information is to better understand how Keygen's visitors use its website and to better provide related content to its visitors. From time to time, Keygen may release non-personally-identifying information in the aggregate, e.g., by publishing a report on trends in the usage of its website.
We also collect potentially personally-identifying information like Internet Protocol (IP) addresses for all API users, as well as for Dashboard users (what information is collected is detailed in 1.10. and 1.11.). These logs are retained for up to 30 days (our data retention policy is detailed in 1.12.).
We do not keep logs for requests to our Marketing or Documentation sites, but IP address and other personally identifiable information may be collected from website visitors for one of our Subprocessors (all of which are listed in 1.9.).
2.2. Aggregated statistics
Keygen may collect statistics about the behavior of visitors to its websites. Keygen may display this information publicly or provide it to others. However, Keygen does not disclose personally-identifying information other than as described below.
For example, you may not be able to log into your Keygen account's Dashboard without cookies enabled, for technical reasons.
2.3.1. Cookies we set
- We set
keygen-cookie-consent-*cookies to keep track of your privacy and tracking preferences. You can adjust your consent for these cookies at any time by clicking here.
- We set
keygen-session-store-*cookies so you don't need to login every time you use the Dashboard, which includes related cookies which determine how long the previously mentioned session cookie is valid for.
- We use your browser's
localStorageAPI on our site to keep a history of your preferences for displaying documentation, e.g. we'll display docs in the programming language you prefer using.
Other cookies may be set by our trusted third-parties listed above (our Subprocessors). If you're inside of the EU, we employ an opt-in system for all third-party cookies. If you're outside of the EU, we employ an opt-out system. Regardless, you can adjust your preferences at any time by clicking here.
2.4. Disclosure of personal information
We do not sell, trade, or otherwise transfer your information to third-parties. This does not include sharing a limited subset of your information with trusted third-parties (our Subprocessors, which are outlined in 1.9.), who assist us in operating our website, conducting our business, or servicing you, so long as those parties agree to process this information in accordance with their DPA.
Personal Information may be disclosed in limited circumstances, including, but not limited to meeting any applicable law, regulation, legal process, or enforceable governmental request; the investigation of potential violations; addressing fraud, security, or technical issues; to protect and defend the rights or property of Keygen; or in an emergency threatening an individual's life, health, or security. We reserve the right to disclose your personal information as required by law or when we believe that disclosure is necessary to protect our rights and/or comply with a judicial proceeding, court order, or legal process.
2.5. Third-party content
2.6. COPPA compliance
We are in compliance with the requirements of COPPA (Children's Online Privacy Protection Act), we do not collect any information from anyone under 13 years of age. The Act was passed by the U.S. Congress in 1998 and took effect in April 2000. COPPA is managed by the Federal Trade Commission (FTC). Our website, products and services are all directed to people who are at least 13 years old or older. If you are under 13 years old, you cannot use our services.
2.7. Business transfers
If Keygen, or substantially all of its assets were acquired, or in the unlikely event that Keygen goes out of business or enters bankruptcy, user information would be one of the assets that is transferred or acquired by a third party. You acknowledge that such transfers may occur, and that any acquirer of Keygen may continue to use your personal information as set forth in this policy.
2.9. Terms of Service
Please also visit our Terms of Service section establishing the use, disclaimers, and limitations of liability governing the use of our services.
If there are any questions regarding this document, you may contact us at [email protected].