Does the term "certificate authority" refer to the organization issuing certificates (symantec, comodo, let's encrypt, ...) or to the device and software that issues certificates from CSRs or both?
When speaking about a trustworthy "Certificate Authority", we refer to the organization/entity issuing the certificates, and not the tool used to generate them. It refers to the entity in the "Issuer/Issued by" field of your certificate (e.g. DigiCert for this website). Thus, if you issued your own certificates using the same tools as DigiCert, say OpenSSL, you would still not be a CA trusted by most browsers. You could, of course, be a trusted CA within your organization/network/device group.
Does the term "certificate authority" refer to the organization issuing certificates (symantec, comodo, let's encrypt, ...)
or to the device and software that issues certificates from CSRs or both?
In practice, yes.
A Certification Authority (CA) is defined as follows by RFC 5280:
Following is a simplified view of the architectural model assumed by the Public-Key Infrastructure using X.509 (PKIX) specifications.
The components in this model are:
CA: certification authority;
CAs are responsible for indicating the revocation status of the certificates that they issue. Revocation status information may be provided using the Online Certificate Status Protocol (OCSP) [RFC2560], certificate revocation lists (CRLs), or some other mechanism. In general, when revocation status information is provided using CRLs, the CA is also the CRL issuer. However, a CA may delegate the responsibility for issuing CRLs to a different entity.
Clearly this is an organizational definition rather than a description of necessary software components; even the discussion of how revocation works suggests "This, or that, or, you know, something else if you want" - it describes a responsibility rather than a technical requirement.
That being said, in practice, the term CA is often used to describe the technical bits that permit an organization to generate their own certificates. This is a reflection of the fact that what makes a CA trusted is... choosing to trust them. From RFC 5280 again:
A certificate user should review the certificate policy generated by the certification authority (CA) before relying on the authentication or non-repudiation services associated with the public key in a particular certificate. To this end, this standard does not prescribe legally binding rules or duties.
The list of trusted CAs will vary from OS to OS and potentially program to program... see, for example, this thread for Firefox:
We don't have a principled position against accepting admin-defined certs, or against accepting admin-defined certs which are provisioned using OS APIs and stores. However, we do not want to trust a root certificate on an entire platform by default just because the OS vendor trusts it. Even providing the option of switching to the OS store from our store means that some public sites would work in some Firefox installs and not others, which is not good for web compatibility.
Once you get to that point where organizations might set up their own CA, once you start mucking with the Trusted Root CA store to customize it for your environment, the term CA comes to mean "that server/software" and not so much "the authority".
So you will definitely hear people say "CA" when they mean "our installation of Microsoft Certificate Server which acts as a Trusted CA for our internal users."